Re: Thread implementations...
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Fri, 26 Jun 1998 08:20:40 +1000
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