Messages in this thread | | | Date | Fri, 17 Sep 1999 08:38:19 -0700 | From | Dan Kegel <> | Subject | sigwaitinfo(), close(), siginfo_t, and user data |
| |
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/
| |