Subj : Re: How to manage time-slicing in Pthreads programs? To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Mon Feb 21 2005 03:39 pm "David Schwartz" writes: > Agreed, in principle. And the solution is trivial in principle, a > coordination layer that all libraries talk to. The problem is, this solution > does not exist in UNIX and it does in Windows. This is one area where > Windows got it right and Unix got it wrong. > > The kernel provides adequate facilities to get it right if all user > libraries talked to some coordination library that distributed the signals. > The problem is that this coordination layer does not exist and would not > work unless all code used it. Researching integration of event loops is on my TODO list. It doesn't have to be a single library, as long as multiple libraries of that kind can be integrated. http://www.freedesktop.org/Software/dbus As far as I see, dbus can either run its own event loop or can be plugged into some other event loops. It provides ready integration with glib and Qt event loops. If all libraries are written in this style, then the programmer must choose one of them as the primary event loop provider and make a tree: the root implements the event loop, and a child of each node is plugged to the event loop of the parent. This should work as long as interfaces are compatible enough to be plugged. The implementation of my language Kogut can't do this yet: it insists on implementing its event loop itself. While external libraries which want to be notified when a descriptor is ready can be probably plugged into it (this will probably require some improvements), it can't coexist with another library which wants to be the dispatcher. Unless the programmer doesn't care that Kogut threads don't run, but this would be bad. I will try to design an interface which lets it connect to other event loops, and improve the capability of connecting other event loops into it. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .