Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Fri, 17 Sep 1999 22:08:07 +0100 (BST) | Subject | Re: sigwaitinfo(), close(), siginfo_t, and user data |
| |
Hi,
On Fri, 17 Sep 1999 08:38:19 -0700, Dan Kegel <dank@alumni.caltech.edu> said:
> 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).
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |