concurrency in server SDK - aha!

mindlube

Hi all, after much digging in the forum archives I see this is practically a FAQ . So consider adding to your API docs for the Server SDK:

"ExitGames.Concurrency is retlang (http://code.google.com/p/retlang/)
with a few minor changes"

If it's in your docs, I sure didn't see it anywhere. The Features and Quickstart sections are very helpful, plus the quicktime slideshow, the Examples/ and Tests/ in the source code are very informative. It will save future users of your SDK a lot of time & headache trying to figure out how to implement Fibers and Channels in their apps. Thanks

Philip

Thanks for the hint - you are right ...
we are in the mids of finalizing 3.0 and started updating documentation and we'll take your suggestion in consideration.

mindlube

Thanks Philip! Also would love to see the 3.0 documentation, even if it's considered Beta!

duke

Do you know what the "minor changes" are? I'd rather use retlang so I can get automatic updates and such via Nuget and build on top of that.

Philip

Well that part of our code has stayed untouched for a long time - it has proofed to be very stable .

We updated our code to the retlang version 1.0.5 release r424 from 10/14/2010 - we changed
- the behavior of the poolfiber stopping after an unhandled exception
- changed subscribe on Concurrency.Channels.Channel not beeing thread safe
- made the DispatcherAdapter mono compatible
- And probably most interesting for all of you changed the following behavior:

        public void Enqueue(Action action)
        {
            // removed to ensure that queued actions are always executed
            ////if (this._started == ExecutionState.Stopped)
            ////{
            ////    return;
            ////}

            lock (this.@lock)
            {
                this.queue.Add(action);
                if (this.started == ExecutionState.Created)
                {
                    return;
                }

                if (!this.flushPending)
                {
                    this.pool.Queue(this.Flush);
                    this.flushPending = true;
                }
            }

            this.CounterEnqueue.Increment();
        }

There has been some discussion on these behavior change in our forum ... we don't remember the reasoning that lead us to make this change (from march 2010) -
we have kept it for backwards compatibility.

Of course if you prefer to use the "original" for your code you can do that - but to be honest I don't see really why as far as I can see not much happend on retlang since we updated - but its up to you.

duke

The reasoning for using Retlang vs the Exitgames implementation would be so that I can use it in other places without unnecessarily referencing the ExitGamesLib with all the extra functionality.