On implementation of select and poll
Ripunjay Tripathi
point me the right place.
I was going through some aspects of select and poll system call and
caught up by a confusion.
my question is as follows -
I supply a list of lets (say 10) descriptors to select/poll and
specify a time out value. Now these calls will scan the entire list of
descriptors for readability or writability as specified. Does the call
returns before the completion of first scan, if the system call finds
a condition to be true on a descriptor or an error occurs on any of
these descriptors ?
Regards,
Ripunjay Tripathi
Rob Warnock
+---------------
| I supply a list of lets (say 10) descriptors to select/poll and
| specify a time out value. Now these calls will scan the entire list of
| descriptors for readability or writability as specified. Does the call
| returns before the completion of first scan, if the system call finds
| a condition to be true on a descriptor or an error occurs on any of
| these descriptors ?
Are you asking if "select()" can ever indicate multiple descriptors
in the return value? The answer is "yes", though it may depend upon
the operating system. For example, in FreeBSD "select()" will return
*ALL* of the ready descriptors. From "man 2 select" on FreeBSD 6.2:
On return, select() replaces the given descriptor sets with subsets
consisting of those descriptors that are ready for the requested
operation. The select() system call returns the total number of
ready descriptors in all the sets.
And in Linux 2.6.18, there is similar language:
On success, select() and pselect() return the number of file
descriptors contained in the three returned descriptor sets
(that is, the total number of bits that are set in readfds,
writefds, exceptfds) which may be zero if the timeout expires
before anything interesting happens.
So if you're trying to write portable code, you must assume that
*every* scan is "completed", until some scan returns a non-zero
number of ready (and/or error) descriptors (or there is a timeout).
You cannot assume that only the first ready event will be reported.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ripunjay Tripathi
Thanks for the reply. just needed a second opinion.
David Schwartz
wrote:
> I supply a list of lets (say 10) descriptors to select/poll and
> specify a time out value. Now these calls will scan the entire list of
> descriptors for readability or writability as specified. Does the call
> returns before the completion of first scan, if the system call finds
> a condition to be true on a descriptor or an error occurs on any of
> these descriptors ?
If, when you call 'select' or 'poll', any descriptors in your set are
ready for the operation selected, and none of them are invalid
descriptors, *all* ready descriptors will be reported.
If any of your descriptors are invalid, no events will be reported to
you. You will just get a 'EBADF'/'EINVAL' error.
If a descriptor becomes invalid while a 'select' or 'poll' is pending
for it, the results are undefined.
DS
Ripunjay Tripathi
David,
I get a doubt on your statement about your "UNDEFINED" stuff.
About every OS atleast LINUX and AIX have POLLINVAL and POLLHUP in
case fd goes invalid while in action.
I request a clarification.
David Schwartz
wrote:
> > If a descriptor becomes invalid while a 'select' or 'poll' is pending
> > for it, the results are undefined.
> I get a doubt on your statement about your "UNDEFINED" stuff.
> About every OS atleast LINUX and AIX have POLLINVAL and POLLHUP in
> case fd goes invalid while in action.
> I request a clarification.
You mean "in case fd goes invalid while in action, and the
implementation is able to detect and report this", don't you? It is
impossible for the implementation to detect this reliably.
Until and unless 'select' or 'poll' detects something, there is no way
you can know that you are actually in 'select' or 'poll' (as opposed
to about to enter it). So there is no way to define the time interval
during which this would be detected.
Consider:
1) Thread A is coded to call 'select' or 'poll'.
2) Some time passes, but no events or errors have occurred.
3) Thread B closes one of the sockets thread A called 'select' or
'poll' on.
4) Thread C opens a socket and gets the same descriptor thread B
closed.
5) Thread A cannot possibly be guaranteed to detect the operation
threads B and C did now, because there is no way to know whether it
finished entering the 'poll' or 'select' operation before or after
steps 3 and 4.
So the only case in which you could possibly expect to detect it (when
on events or errors have occurred previous) is the one case in which
it can't be guaranteed (because it's not even guaranteed you have
entered the function yet).
DS
Casper H.S. Dik
>> If, when you call 'select' or 'poll', any descriptors in your set are
>> ready for the operation selected, and none of them are invalid
>> descriptors, *all* ready descriptors will be reported.
>>
>> If any of your descriptors are invalid, no events will be reported to
>> you. You will just get a 'EBADF'/'EINVAL' error.
>>
>> If a descriptor becomes invalid while a 'select' or 'poll' is pending
>> for it, the results are undefined.
>>
>> DS
>David,
>I get a doubt on your statement about your "UNDEFINED" stuff.
>About every OS atleast LINUX and AIX have POLLINVAL and POLLHUP in
>case fd goes invalid while in action.
>I request a clarification.
Same is true for Solaris.
(Select is clearly not very useful when one of the fds is bad)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Ripunjay Tripathi
I understand the race condition you described. But my question is
about how the implementation is most expected to behave
and not how should a progarmmer code and what should programmer
assume. The query was straight forward -
Please ignore the case 3 of thread C which accidentally recieves a
same descriptor just closed.
What should poll return in case it sees an error at descriptor like as
u said thread B closed the descriptor ? Alternatively if you can tell
whats the significance of POLLINVAL or POLLHUP ?
Regards,
Ripunjay Tripathi
Jorgen Grahn
Yes, that should be obvious in any select man page.
I also note that he should not worry that some fds may be ready even
though select() didn't report them as ready. There is nothing he can
do about it except what he would do anyway: do his processing of the
fds he knows, and then call select() again.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ripunjay Tripathi
Here, the intoduction of Thread C that receives the same socket
descriptor that was closed in some thread B gives an interesting twist
to the story. But from system call developers view, as I know, the
poll/ select puts these descriptors in drivers hands and sleeps after
the initial scan of the fd set. Now its device driver's responsibilty
to wake up the system call (I mean the thread ) and report the
descriptor which is ready. In the case as explained by David (Thread C
case), since the original descriptor was closed, the device driver
will NOT wake up the system call, rather it will inform about the
error.
Please tell me if I am living in some fantasy or something close to
truth.
Regards,
Ripunjay Tripathi
David Schwartz
wrote:
> What should poll return in case it sees an error at descriptor like as
> u said thread B closed the descriptor ?
There is no should here. As I explained, it's fundamentally a race
condition.
> Alternatively if you can tell
> whats the significance of POLLINVAL or POLLHUP ?
I was a bit imprecise, lumping 'poll' and 'select' together.
The 'POLLHUP' function detects a disconnect on a perfectly valid
connection. There is no race or program there with either 'select' or
'poll'. The difference is that 'poll' will tell you that it's a
disconnect, while 'select' will make you call 'read' or some other
function to determine the result.
The 'POLLNVAL' is the 'poll' return code when a descriptor is invalid
before you could possibly have called 'poll'. An implementation may or
may not give you such a return code if the descriptor subsequently
becomes invalid. As I explained, it is logically impossible for it to
promise to do so.
DS
David Schwartz
wrote:
> Here, the intoduction of Thread C that receives the same socket
> descriptor that was closed in some thread B gives an interesting twist
> to the story. But from system call developers view, as I know, the
> poll/ select puts these descriptors in drivers hands and sleeps after
> the initial scan of the fd set. Now its device driver's responsibilty
> to wake up the system call (I mean the thread ) and report the
> descriptor which is ready. In the case as explained by David (Thread C
> case), since the original descriptor was closed, the device driver
> will NOT wake up the system call, rather it will inform about the
> error.
>
> Please tell me if I am living in some fantasy or something close to
> truth.
You are living in a fantasy. There is no way to assure that thread C
completes its work before thread A is blocked on the descriptor. So
the behavior is fundamentally indeterminate. (Thread A may or may not
be blocked when thread B does its work and it may or may not be
blocked when thread C does its work.) Systems do not provide
guarantees that are impossible to rely on because the sole point of a
guarantee is to rely on it.
Simply put, an application that uses shared resources must make sure a
shared resource is not freed or released when another thread or
process is or might be using it. Otherwise, all bets are always off.
Race conditions are inevitable and so behavior simply cannot be relied
on.
DS
Jorgen Grahn
...
> (Select is clearly not very useful when one of the fds is bad)
Bad fds are clearly not very useful as arguments to select() ;-)
Barry Margolin
Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Wed, 2009-10-28, Casper H.S Dik wrote:
> ...
> > (Select is clearly not very useful when one of the fds is bad)
>
> Bad fds are clearly not very useful as arguments to select() ;-)
>
> /Jorgen
Put simply: bad fds are bad.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Ripunjay Tripathi
Thanks to all for participation. Especially Rob and David.
David,
Please go through the code for select system call - TCP/IP
Illustrated, Volume 2: The Implementation Chapter 16, section 16.13
You can easily see what I said above is correct. However, the race
conditions that you are emphasizing on are correct and intutive.
Anyways thanks for pushing me to find the code :-).
Regards,
Ripunjay Tripathi
David Schwartz
wrote:
> David,
> Please go through the code for select system call - TCP/IP
> Illustrated, Volume 2: The Implementation Chapter 16, section 16.13
> You can easily see what I said above is correct.
It doesn't matter what particular implementations happen to do. You
cannot code based on that.
> However, the race
> conditions that you are emphasizing on are correct and intutive.
> Anyways thanks for pushing me to find the code :-).
You're welcome. But do yourself a huge favor and design to
specifications, not implementations.
DS