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

2010-12-21 Thread Rodrigo Kumpera
On Thu, Dec 16, 2010 at 4:28 AM, Virgile Bello virgile.be...@gmail.comwrote:

 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


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

2010-12-15 Thread 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?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list