Messages in this thread | | | Date | Fri, 26 Jun 1998 08:20:40 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
Stephen C. Tweedie writes: > Hi, > > Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> writes: > > > Gerard Roudier writes: > > > > > > I did read your proposal. As answer, here is the description of an > > > application program I wrote 5 years ago and that is always alive > > > nowadays. > > > > > > - Completely even driven. > > > - Use SIGIO under UNIX. > > > So when you want to know that a connection has fresh incoming data, > > you get SIGIO when the event comes? Now how do you know *which* FD > > received new data? AFAIK the signal handler has no knowledge of which > > FD had the I/O completed. It looks to me you are then forced to > > attempt a read on *every* FD. > > > How on earth does this scale with large numbers of FDs? > > I've just been implementing this for 2.1. :) The 2.1 kernel already > supports posix.1b (aka posix.4) realtime signals, and those signals can > be queued with one word of data per queued signals. Multiple signals > with the same signum can be queued; they will be delivered in order.
Yeah, POSIX realtime signals are much better. However, my point was that I don't see how his code scales *now* (i.e. machines with plain UNIX signals).
> With a fcntl(fd, F_SETSIG, signum), you can tell the kernel to send a > realtime signal with the specified signum instead of SIGIO for all > unblock events on that file descriptor. The signal will be queued with > the fd as an argument to the signal handler. If the signal queue > overflows, the kernel will deliver a generic SIGIO to let the > application know it should select() against all fds to find which ones > may have missed a realtime signal.
But once again we have a non-standard hack for Linux. If we do that then as far as I'm concerned, we may as well implement "readiness queues". Anyway, I'm pursuing a scalable solution that works for other UNIX systems.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |