Re: To be smug, or not to be smug, that is the question

Alain Williams (addw@phcomp.co.uk)
Tue, 19 Jan 1999 18:32:46 +0000


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/