Bug 1875 - poll() isn't SUSv3 compliant-- See Bug 546
Summary: poll() isn't SUSv3 compliant-- See Bug 546
Status: REJECTED INVALID
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: io_other
URL:
Keywords:
Depends on: 546
Blocks:
  Show dependency tree
 
Reported: 2004-01-15 15:21 UTC by Loic Domaigne
Modified: 2004-01-29 20:29 UTC (History)
0 users

See Also:
Kernel Version: virtually all
Tree: Mainline
Regression: ---


Attachments

Description Loic Domaigne 2004-01-15 15:21:42 UTC
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:

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

So that means that if a POLLNVAL occurs, then it has to be reported. 
Furthermore, the POLLNVAL event means: 

<copy>
POLLNVAL
    The specified fd value is invalid. This flag is only valid in the revents 
member; it shall ignored in the events member.
</copy>

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 
calling poll(). 


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

Regards,
Loic. 

P.S: Similar game with select() I guess...
Comment 1 Andrew Morton 2004-01-16 21:52:34 UTC
Linus quoth:

> > 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 
 are broken.
Comment 2 Loic Domaigne 2004-01-19 23:45:00 UTC
> 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.
http://www.opengroup.org/austin/mailarchives/austin-group-l/msg06554.html
http://www.opengroup.org/austin/mailarchives/austin-group-l/msg06560.html
http://www.opengroup.org/austin/mailarchives/austin-group-l/msg06562.html

Seems that it's not necessarily straightforward for poll(), but not worth the
effort IMHO. 


> Besides, the SuS part quoted in no way implies that the Linux semantics are 
> broken.

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
Linux poll().


Thanks for your time,
Loic. 

Note You need to log in before you can comment on or make changes to this bug.