| View previous topic :: View next topic |
| Author |
Message |
Grant Edwards
Guest
|
 Posted: Fri Aug 29, 2008 7:05 pm Post subject: Re: select() returns Success when device referred by fd no l |
 |
|
On 2008-08-29, Jens Thoms Toerring <jt@toerring.de> wrote:
| Quote: | So one would either need some kind of "atomic" select and do I/O
function to get it right or, without that existing, one would have
to switch to non-blocking mode before the I/O operation is done in
all cases where one wants to make sure one doesn't wait more than a
certain time. Correct?
|
Correct. If you want to make sure you don't block in an I/O
operation you must use non-blocking I/O calls. The results of
select() aren't a guarantee, just a very strong hint. Many
people who write apps using select() in combination with
blocking I/O calls will never have any problems, but if you
wan't to do it the "right" way, you use non-blocking I/O.
--
Grant Edwards grante Yow! FROZEN ENTREES may
at be flung by members of
visi.com opposing SWANSON SECTS ... |
|
| |
|
 Back to top |
Rainer Weikusat
Guest
|
| Posted: Fri Aug 29, 2008 9:15 pm Post subject: Re: select() returns Success when device referred by fd no l |
|
|
jt@toerring.de (Jens Thoms Toerring) writes:
| Quote: | David Schwartz <davids@webmaster.com> wrote:
On Aug 28, 4:53 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
A descriptor shall be considered ready for reading when a call to an
input function with O_NONBLOCK clear would not block, whether or not
the function would transfer data successfully. (The function might
return data, an end-of-file indication, or an error other than one
indicating that it is blocked, and in each of these cases the des-
criptor shall be considered ready for reading.)
A descriptor shall be considered ready for writing when a call to
an output function with O_NONBLOCK clear would not block, whether
or not the function would transfer data successfully.
Notice again the "would", not "will".
As far as I understand this it looks to me more or less like what
I wrote, i.e. that if select() indicates that a file descriptor is
readable a read() call won't block (but nothing else).
A read call *WOULD* not block, had there been one at the time.
Ok, i see your point after re-reading those sentences for about
20 times;-) Sorry for being a bit dense, but then English isn't
my first language and this is a bit of legalese...
|
David is still wrong. He is (and will likely continue this way
forever) confusing a subjunctive refering to a hypothetical past event
with a subjunctive refering to a [future] possibility. The German
(grammar) names for these two would be 'Irrealis' and 'Potentialis'. |
|
| |
|
| Back to top |
Rainer Weikusat
Guest
|
| Posted: Fri Aug 29, 2008 9:21 pm Post subject: Re: select() returns Success when device referred by fd no l |
|
|
Grant Edwards <grante@visi.com> writes:
| Quote: | On 2008-08-29, Jens Thoms Toerring <jt@toerring.de> wrote:
So one would either need some kind of "atomic" select and do I/O
function to get it right or, without that existing, one would have
to switch to non-blocking mode before the I/O operation is done in
all cases where one wants to make sure one doesn't wait more than a
certain time. Correct?
Correct. If you want to make sure you don't block in an I/O
operation you must use non-blocking I/O calls. The results of
select() aren't a guarantee, just a very strong hint.
|
The result of 'select' is 'a guarantee' that a certain condition
was true at the time 'select' checked it. And this condition will not
'automagically' change on its own. Something needs to change it.
For a file descriptor (minus implementation quirks), this must be
something another process which posesses an open file descriptor
refering to the same resource has done in the meantime. |
|
| |
|
| Back to top |
Rainer Weikusat
Guest
|
| Posted: Fri Aug 29, 2008 9:30 pm Post subject: Re: select() returns Success when device referred by fd no l |
|
|
David Schwartz <davids@webmaster.com> writes:
| Quote: | On Aug 28, 10:16 am, Rainer Weikusat <rweiku...@mssgmbh.com> 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).
[...]
| Quote: | 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 ]
| Quote: | 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.
[...]
| Quote: | 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.
[...]
| Quote: | 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. |
|
| |
|
| Back to top |
|
