Messages in this thread | | | Date | Tue, 19 Jan 1999 18:32:46 +0000 | From | Alain Williams <> | Subject | Re: To be smug, or not to be smug, that is the question |
| |
On Mon, Jan 18, 1999 at 10:48:11PM -0800, Dan Kegel wrote: > "Albert D. Cahalan" <acahalan@cs.uml.edu> writes: > > Blocking system calls were a bad idea. Signals were added to unix > > to address the lack of a general event queue. Since longjump won't > > get you out of one of those crummy blocking system calls, some > > fool made signals interrupt system calls. As a patch on top of > > a patch on top of a patch, app programmers need to wrap system > > calls in loops. Patching the brokenness even more, we see Netscape > > talking to itself to get around a stupid race condition. Since > > the unixy API does not support dispatching concurrent system calls, > > someone added the aio_* functions to "fix" it for the limited case > > of simple disk IO. All along the way people find hacks for their > > own immediate problem rather than fixing the API. > > I think he hit a nail on the head somewhere there... > a single uniform mechanism for waiting for stuff was > what I liked so much about select(), but now I see it > isn't up to the task. Sun had a modified select() back in > SunWindows days to allow you to wait for UI events, too; > I wonder if there's an elegant generalization to select() > that could be useful in the future?
AIX select() allows you to wait on message queues as well as FDs.
One thing that I have always thought would be useful is some kind of `serialise_access()', this would allow one process after another to lock some shared resource -- in the order that they joined the queue. Part of the purpose is to remove the wake_everything_up approach that leads to the ``thundering herds'', but also means that it is possible that something waits a *very* long time before it gets it's turn on a popular resouce.
-- Alain Williams
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |