On Wed, 2005-11-09 at 16:41 +0100, Bas Wijnen wrote: > On Wed, Nov 09, 2005 at 03:02:36PM +0100, ness wrote: > > The problem Jonathan pointed out is that *others* will delay. This is not > > the case, as the server will be multithreaded. > > Multi-threaded, or handling data in chunks with an event-loop, like the Glib > main loop that Gtk uses. > > Jonathan, would that solve the problems you are talking about?
It will not. I've already talked about multithreading. Now let me tackle event loops. The problem is that somewhere in the event loop you need to check to see if you are blocking some other incoming request. This can be done with a non-blocking wait, but then the problem is that you need to store the state of the first activity while you go deal with the second. Or the third. Or the 30th.... So yes, I think we can dramatically increase the magnitude of the problem with just about any form of concurrency you care to try. We can convert a program that was not real time into a program that is both not real time and now is subject to storage denial of resource too! shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
