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
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
