[Mono-dev] Mono Tasklets (microthread resuming with different stack, and possibly microthread migration)

[Virgile Bello]

I was wondering a few things concerning Mono.Taskets:

1/ By modifying mono to not throw an exception when marking top-most frame a
second time (using Mono.Continuation.Mark), I figured more behavior could be
covered.

As an example, let's say I Mark and Store in the following stack frame:
== Stack C2() -> Here I Store(0)
== Stack C1() -> Here I Mark
== Stack A2()
== Stack A1()

Next run, I could run B1 again from a different stack to restore B2:
== Stack C2() -> Here I Store(0)
== Stack C1() -> Here I Mark _again_ to update current stack topmost frame,
and then Restore(0) which will add C2 on top of new stack
== Stack B3()
== Stack B2()
== Stack B1()

Basically, this enables Continuation to be resumed later in time, even if
calling stack frame is different.
As a result, MicroThread Scheduler could be rewritten so that it runs in a
"Step()" mode every frame instead of a "Run()" loop (which force to create
thread)
This could even allow to migrate MicroThread on a different Thread (not
tested yet).

So far it seems to work on simple case, can anyone tell me if it could lead
to any issues I could not foresee?
I was especially worried about internal pointer to stack (if there is any)
becoming invalid if base ESP gets shifted (but in that case, I could always
manage to call this function with the same call stack so ESP would be the
same between each "Step()").

2/ I noticed a bug in continuation_mark_frame that could lead to random
crash: https://bugzilla.novell.com/show_bug.cgi?id=659827
3/ So far it is only available on x86/ia64. Is there anything that would
prevent it to work on other platform (esp. ARM/PS3 etc...) in the future?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20101216/6b0d5315/attachment.html