Messages in this thread | | | Date | Mon, 18 Jan 1999 21:17:13 -0500 (EST) | From | "Albert D. Cahalan" <> | Subject | Re: Netscape broken with 2.2.0-pre7 |
| |
Jamie Lokier writes: > On Sun, Jan 17, 1999 at 07:36:43PM +0100, Andi Kleen wrote: >> [somebody]
>>> It doesn't look like a signal thing so much as an abuse of a pipe. >>> It's pretty clear Netscape _could_ use an internal circular buffer >>> instead of an OS pipe. Then again, maybe that would just add to >>> the many memory leaks :-) >> >> It can't. You can't poll a circular buffer in a select/poll. >> That is why the self pipe trick is often used to pass information >> from signal handlers to the main loop. > > You don't need to poll the buffer in select/poll. On entry to select, > if the buffer is non-empty, don't call select... (simple :-) > > If a signal handler inserts into the buffer, it can interrupt the select > call (with EINTR), which can check the buffer before trying again.
No, this is broken. The whole unixy API is broken in fact.
Consider these events:
1. you check the buffer - it is empty 2. a signal arrives 3. you select() because you think the buffer is empty
Time to rant!
I hate to admit it, but Win32 works better. All events arrive the same way. They have a select() equivalent that can handle everything, not just file descriptors. You can do semaphores with it even.
To get this in Linux:
Implement your own API in a library. For every kernel call that could block or cause a signal, use clone() to get a new context. Results must be accessed via a pipe hidden within the library.
Gross? Oh yeah...
I ran into this problem when trying to write a web server on Digital Unix. (they have real aio_* calls) The stupid select() call claims that a regular file is always ready to read without blocking, even when the data is on disk. The stupid aio_* calls won't handle network sockets. Signal handlers can't call most library functions reliably. Ewww.
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.
- 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/
| |