@Richard An awesome reply. I agree, using C#’s generator system as a continuation / co-routine system is a hack on top of a hack in some ways, but only Mono supports actual continuations / co-routines.

I’m thinking, in general, this system just needs a more robust scheduler that can make the connection between a running coroutine and the connected parent object, something I don’t think C# can do by default.

Take a look a Python. First generators were added, and then someone said, “Hey, look, if we allow values to be sent through the generator to the yielding function, we get coroutines!” Then someone said, “If we write a scheduler that shoves these coroutines around, and the code written in the coroutines is written in a certain way with the custom boilerplate that allows these coroutines to work, then we have microthreading!” What you really have, is a situation where you have approximated microthreads that do not have the benefits of proper microthreads. Whether the creators of the generator coroutines and microthreading framework were ever aware of these benefits, is something that could be questioned.

So, what’s my point? Firstly that proper coroutines should make code more readable, not less readable. Secondly, that with a proper microthreading framework you do not need to add these checks in your logic. I am not familiar with the generator coroutine / microthreading implementation you are using, so you will have to work out how good an approximation it is.

Yes, the checks are cumbersome, but I had game logic that is probably still out there pumping away at the moment doing many steps in a microthread along the lines of “Approach target.. check if in process of being garbage collected, check if dead, check if still on that target, .. Still focused and alive? Proceed with next step of the action on that target.” The only reason these checks are still in place, is not because I could not abstract them away completely, but rather that the microthreading framework I used was not finalised at the time I initially wrote the logic. It would have been trivial to replace them after it was, if I had deemed worthwhile. The truth is that there really wasn’t that much entity logic that needed checks like this, most of it was pretty generic, including that generic action performing function that got launched by each entity.

So how would I have gotten rid of these checks on our microthreading framework? Well in Stackless Python you can kill a microthread. This reschedules the microthread but rather than continuing execution where it was yielded, instead an exception (TaskletExit) is raised within it. Nothing catches this exception, it is the natural indicator that the microthread is exiting. Anyway, it unwinds the call stack and the microthread exits and is garbage collected. What I would have done (and have done in other projects) is to store a reference to the action performing microthread when it is created. Then when an entity starts a new action, or gets an event indicating it has been killed, or removed from the game environment, that tasklet can be killed.

Is it possible for you to raise an exception through your generator from your scheduler, and to kill one of your microthreads in this way? I do not know.

Since we’re specifically talking about using coroutines in a separate thread to execute actions that may take place over several frames (and communicate back to other threads), there are all the usual issues of making sure the invariants truly stay invariant while a function (or in this case coroutine) is running, but between yields, presumably we can get updates that would terminate (or put on hold) coroutines which are no longer valid, such as “this monster just died.”

I get the feeling I might be misunderstanding the problem. I’m by no means an expert with this stuff, but I hope that helps.

@Yilmaz Unfortunately the MS CLR has no concept of actual co-routines and ownership. You have to hold on to the enumerator which is essentially the stack information.

@Tomat Not sure Trampolining solves my problem.

In that case action will break sequence if something goes wrong according to action’s logic.

Or even get rid of enumeration style and do pure continuation as explained here “Stackless C# – Trampolining, Continuations and Erlang in .Net” http://refractalize.blogspot.com/2009/02/stackless-c-trampolining-continuations_21.html