On Thu, Dec 16, 2010 at 4:28 AM, Virgile Bello <virgile.be...@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.
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list