Messages in this thread | | | Date | Fri, 17 Sep 1999 22:18:17 +0200 | From | Jamie Lokier <> | Subject | Re: sigwaitinfo(), close(), siginfo_t, and user data |
| |
Dan Kegel wrote: > "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
Use non-blocking I/O. Always use non-blocking I/O. O_NONBLOCK.
Even with select(), a descriptor that's marked "available for write" might not be by the time you try, because the buffer space might not be available any more.
Basically, treat the result of select(), poll() or sigwaitinfo() as a hint. A pretty good hint, guaranteed to say "yes" at least often enough. In fact sometimes it's worth trying a non-blocking write even before getting the hint, if you've acquired the urge to write to an fd for the first time in a while.
[This also applies to reads, but I couldn't think of a good example]
> 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. ... > I know, I can just do a hash table lookup on the file descriptor, > so this wouldn't save much time.
Just use an array: mydata[fd]. The kernel uses an array, so you can too.
> 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.
Another good reason not to add the feature.
-- Jamie
- 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/
| |