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

Rodrigo Kumpera kumpera at gmail.com
Tue Dec 21 17:58:42 EST 2010


On Thu, Dec 16, 2010 at 4:28 AM, Virgile Bello <virgile.bello at gmail.com>wrote:

> 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()").
>

Yes, all sort of internal pointers will break with this. This means any call
with byref args or with a this vtype will break. Fixing this is not simple
at all. Thread migration is also an issue as those frames could have taken a
lock and migration would lead to corruption (easy to work around thou).



>
> 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?
>

No, someone just have to submit code for those targets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20101221/a40a66ae/attachment.html 


More information about the Mono-devel-list mailing list