[Mono-dev] Mono Continuations and MicroThreads

Tomi Valkeinen tomba at bat.org
Fri Apr 21 03:42:08 EDT 2006


> 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 

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.


More information about the Mono-devel-list mailing list