sigwaitinfo(), close(), siginfo_t, and user data

Dan Kegel (dank@alumni.caltech.edu)
Fri, 17 Sep 1999 08:38:19 -0700

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.
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

IMHO close() should go through and purge the signal queue of
events related to the file descriptor being closed.
Does Linux already handle this correctly? (What source file
would this be in?)
Is there a standards body looking at standardizing the F_SETSIG +
extended siginfo_t + realtime signal queue feature?

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?

I know, I can just do a hash table lookup on the file descriptor,
so this wouldn't save much time. Still, if people are thinking
of tweaking the API someday, this would be a convenient feature.

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.
- Dan

-- 
(The above is my opinion alone, and not that of my employer)


-
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/