Bug 7609 - poll(2) semantics on read-EOF differ from Solaris 10 semantics
Summary: poll(2) semantics on read-EOF differ from Solaris 10 semantics
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: fs_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-01 03:25 UTC by Matti Aarnio
Modified: 2008-09-23 08:55 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.9, 2.6.15
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Matti Aarnio 2006-12-01 03:25:43 UTC
While converting old code using select(2) to use poll(2), its deployment
on Solaris 10 SPARC machine did show that Solaris does return (in revents)
POLLEOF without POLLIN if the file (socket) is in read-EOF condition.

Linux 2.6.15 does return POLLIN even for EOF cases.
Does it return it WITH the POLLEOF flag ?  That was not looked for.

I can't entirely blame Linux for returning this result -- it is very convenient
for conversion from select() to poll(), after all, but being a mismatch against
Solaris, code portability issues raised their ugly head..
Nor can I say what happens at latter kernel versions.
Comment 1 Michael Tokarev 2007-03-29 06:55:52 UTC
There's NO POLLEOF flag on Linux.  It's Solaris-specific it seems.
Comment 2 Natalie Protasevich 2008-04-06 12:11:50 UTC
Matti, if you are still interested in such semantics, maybe you can elaborate what the flag is for in read-EOF condition. Maybe it will be possible to map this case to Linux functionality and explain the difference.

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