Re: select() returns Success when device referred by fd no longer exists
- From: Rainer Weikusat <rweikusat@xxxxxxxxxxx>
- Date: Fri, 29 Aug 2008 18:30:37 +0200
David Schwartz <davids@xxxxxxxxxxxxx> writes:
On Aug 28, 10:16 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:
It is almost literally identical to the definition of select:
A descriptor shall be considered ready for reading when a call
to an input function with O_NONBLOCK clear would not block[1]
No, notice the "would". This is *very* different from "will". This
"would" is referring to a hypothetical concurrent operation, not a
future actual one.
It refer to a future possible one. Otherwise, the sentence would
need to use some 'past tense form' ('would not have blocked', which
is, AFAIK, formally incorrect, or 'had not blocked', which, again
AFAIK, would be formally correct).
[...]
It's like saying that 'statfs' tells you how much disk space you can
use without getting a 'disk full' error.
This is still a wrong analogy: 'statfs' returns the amount of free
disk space at the time of the call. Under normal conditions, the
amount can change at any time because the disk (being mounted
somewhere in the filesystem tree) is a resource shared by all running
processes, each of which may consume (or free) diskspace whenever it
actually runs. If the resource whose status select has reported is
shared depends both on the resource and on the execution history of
the system, ie which other processes can acess it, for instance,
because they have an open file descriptor refering to it, too. It need
not be shared, although it may.
[ incorrect interjection removed ]
Exactly. Network connections are always shared, because they have more
than one end.
This discussion refers only to the state on the local system, which
the remote system cannot change. At best, it could send a message
requesting such a change.
[...]
The condition which caused select to indicate that a particular
descriptor would be readable is 'remembered somehow' (otherwise,
select couldn't have checked it)
Huh? The 'select' function checked it, but that check is immediately
forgotten.
That's why I was writing about the condition.
[...]
and without 'something' happening
which changes this state, it won't change.
Right, but something can happen. The system might run low on memory
and have to drop some network packets.
If you ever implement that buggy kernel, please put a BIG note on it:
This has been written to demonstrate that received data is trash.
Don't use.
.
- References:
- Prev by Date: Re: select() returns Success when device referred by fd no longer ???exists
- Next by Date: Re: Bad File Descriptor error
- Previous by thread: Re: select() returns Success when device referred by fd no longer exists
- Index(es):
Relevant Pages
|
