[lkml]   [1999]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: sigwaitinfo(), close(), siginfo_t, and user data

    On Fri, 17 Sep 1999 08:38:19 -0700, Dan Kegel <>

    > Q1. Consider a program that sets fd's to deliver realtime signals
    > when they are ready for I/O, blocks the signal,
    > and uses sigwaitinfo() to pull signals off the queue.

    SIGIO (and realtime SIGIO too) is only defined for socket-style, pipe,
    or certain char-mode file descriptors, not for regular files. SIGIO is
    _always_ associated with a fd capable of running in O_NONBLOCK mode, and
    is intended to be used with O_NONBLOCK.

    > There is a potential race condition:
    > "fd 4 ready for read" placed in rt signal queue
    > program closes fd 4
    > program opens fd 4 again, uses F_SETSIG to associate it with rt signal
    > program calls sigwaitinfo(), sees that fd 4 is ready for input
    > program tries to read from fd 4, blocks forever

    Not if you have O_NONBLOCK set.

    > Q2.
    > Right now, the siginfo_t for SIGIO has the following fields:
    > int si_band; /* Band event for SIGPOLL. */
    > int si_fd;
    > In my applications, I have to search a table to find the object
    > associated with a particular file descriptor. It'd be nice
    > to not have to search. How foolish is it of me to wish that
    > the siginfo_t had an additional field, e.g. void *si_userdata,
    > to hold a pointer's worth of user data associated with the
    > file descriptor?

    It's called "si_value", and it just so happens that the siginfo address
    used for si_value is not used by either si_band or si_fd. We could add
    this if we stored the value in every async file descriptor and added an
    ioctl to set it.

    > If this feature were added, it would be even more important
    > to avoid delivering stale siginfo_t's, as they could cause a
    > crash, not just a hang.

    Indeed. :) There is, however, no way to flush a given fd's signals in
    the current kernels. All you can do is flush all signals of a given
    signum (by temporarily setting the handler to SIG_DFL).


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

     \ /
      Last update: 2005-03-22 13:54    [W:0.022 / U:0.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site