[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Thread implementations...

    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:43    [W:0.020 / U:0.992 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site