Peter Somogyi raised the Bug546 on the Austin Group's webmaster.
Here's the summary of our discussion to this respect.
As specified in SUSv3:
In addition, poll() shall set the POLLHUP, POLLERR, and POLLNVAL flag in
revents if the condition is true, even if the application did not set the
corresponding bit in events.
So that means that if a POLLNVAL occurs, then it has to be reported.
Furthermore, the POLLNVAL event means:
The specified fd value is invalid. This flag is only valid in the revents
member; it shall ignored in the events member.
This is in particular the case when the descriptor is closed while the
application is still poll'ing on it.
IOW it requires poll() to set the POLLNVAL revent flag for an fd
that "becomes" invalid during the timeout period, and poll() should return.
Obviously, the same behavior should happen if the fd _IS_ already invalid when
Stated clearly: the issue raised _IS_ a *BUG* and should be fixed (virtually
every kernel versions are concerned...) Pls refer eventually to the
discussion "Comment on poll()" on the Austin Group mails archives for more
P.S: Similar game with select() I guess...
> > It appears to be a bug: poll doesn't notice close calls and thus doesn't
> > wake up.
That's not a bug, it's a feature.
The fd isn't closed. It's open when the poll starts, and poll will have a
reference to the thing. So it never did close as far as poll is concerned.
A threaded app that depends on some close semantics is just broken, and
SuS or not doesn't matter.
Besides, the SuS part quoted in no way implies that the Linux semantics
> The fd isn't closed. It's open when the poll starts, and poll will have a
> reference to the thing. So it never did close as far as poll is concerned.
I can understand that.
> A threaded app that depends on some close semantics is just broken, and
> SuS or not doesn't matter.
I fully agree with that point of view, and so did others too. See e.g.
Seems that it's not necessarily straightforward for poll(), but not worth the
> Besides, the SuS part quoted in no way implies that the Linux semantics are
Not really sure on that, and that's would be nice to know why. But, gee, I guess
you have likely more urgent things to manage ;-)
I suggest to reject that bug as INVALID like the previous one, and hope this
discussion will serve for future references if someone has doubts about the
Thanks for your time,