[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.019 / U:1.220 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site