[Mono-dev] Mono Continuations and MicroThreads

[Denis ERCHOFF]

Hi,

The perfect thread scheduler is the one that give the same execution 
period time for all threads :)

So a first ( incomplete ) idea is coming to me :

If :

* You define a maximum time of execution foreach microthread.
* the scheduler call the microthread run method.
* An OS thread loop until the max time is reached for the current 
microthread or the current microthread returns. If the microthread 
didn't return before the defined max time, the scheduler force this 
microthread to save his stack and it switch to an another microthread.

I hope this is not to hard to implement :) .

p.s. : for more functional idea, look at Fair thread -> 
http://www-sop.inria.fr/mimosa/rp/

Tomi Valkeinen a écrit :
> Hi,
>
>> As i remember, previous version of your scheduler class has a "strong 
>> reference" to the socket manager class.
>>
>> What about an application does not using sockets ?
>> What about another socket implementation ( my case ) ?
>>
>> This is not a crucial fix, but i think it is better to keep out the 
>> Socket management. A programmer will use a microthread to update his 
>> socket ;).
>
> The socket manager does not prevent you from doing anything. If you 
> don't use the included socket implementation, the manager does not do 
> anything, so you can as well use standard .Net sockets in your code. 
> However, then you have to do all the work in non-blocking way, because 
> if you block one microthread, all microthreads are frozen. You have to 
> remember that microthreads are not OS threads =).
>
> I've thought of implementing a generic way to add these "managers" to 
> the scheduler, so you could implement blocking code (blocking in 
> microthread sense, not in OS thread sense) similar to the socket 
> implementation I have. But that's not so simple:
>
> The basic problem here is about events. If we don't want to run in a 
> busy loop, constantly polling for new events and using 100% of the 
> CPU, there has to be some place where we wait for events or sleep for 
> a certain time. Sleeping is not good because we can't know when the 
> next event will come, and we would usually sleep too long.
>
> In my current code this place, where we wait, is in the socket manager 
> when we Select() the sockets. This works because currently socket 
> events are the only events the microthreads react to. If we'd like to 
> add a new type of event, for example input from console, we'd be in 
> trouble as there's no way we could wait for events both from sockets 
> and from console in the same place. Currently you'd have to have a 
> microthread that polls the console input in a loop and sleeps for some 
> milliseconds between the polls.
>
> I'm not sure yet how to solve this event problem. Perhaps a separate 
> OS thread that listens to the event, and notifies the OS thread where 
> microthreads run via a socket.
>
>  Tomi
>
>