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.
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.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu