On 9/16/2011 2:16 AM, Andrew Bennetts wrote:
> On Tue, Sep 13, 2011 at 12:31:29PM -0000, John A Meinel wrote:
>> (If you do select.select([r], [], []) and the far side of r has
>> been closed, would select hang forever?, maybe I need to pass it
>> in the last list as well.)
>
> Beware Windows (and diverse platforms in general): the third
> argument to select has a subtly different meaning there. I forget
> the exact details, just that Linux tends to use the exceptfds set
> for fewer things (e.g. when a TCP URG bit was received?), and
> Windows tends to signal some connection errors there as well.
>
> Basically, be extra sure to test on both Windows and Linux :)
>
So, I can understand the desire to pass the file descriptor to
'errors'. But what do you actually *do* if it returns something there:
If a process is blocked on a select() while waiting for input from a
socket and the sending process closes the socket, the select() notes
this as an exception rather than as data. Therefore, if the select()
is not currently looking for exceptions, it waits indefinitely.
However, my empirical testing disproves this. Specifically, if the
client process closes their end of the socket, select() returns that
read is no longer blocked, and if you recv() on it, it returns there
are no bytes to be consumed (thus you must be closed).
Now maybe select(, , errfds) is very implementation specific. I don't
have any problem using it, but I have no idea what to *do* with the
results.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/16/2011 2:16 AM, Andrew Bennetts wrote:
> On Tue, Sep 13, 2011 at 12:31:29PM -0000, John A Meinel wrote:
>> (If you do select.select([r], [], []) and the far side of r has
>> been closed, would select hang forever?, maybe I need to pass it
>> in the last list as well.)
>
> Beware Windows (and diverse platforms in general): the third
> argument to select has a subtly different meaning there. I forget
> the exact details, just that Linux tends to use the exceptfds set
> for fewer things (e.g. when a TCP URG bit was received?), and
> Windows tends to signal some connection errors there as well.
>
> Basically, be extra sure to test on both Windows and Linux :)
>
So, I can understand the desire to pass the file descriptor to
'errors'. But what do you actually *do* if it returns something there:
rs, _, xs = select.select([fd], [], [fd], timeout)
if xs:
????
Do I:
1) Ignore xs, but assume that it makes it more likely that select()
will raise an exception?
2) Treat xs having a file descriptor as meaning the client has timed
out, and thus we should just clean up and go home?
3) Try to do something like read on the descriptor in order to figure
out what is actually wrong with it?
The only place I've been able to find anything about errfds was: www.mkssoftware .com/docs/ man3/select. 3.asp
http://
Where it says:
If a process is blocked on a select() while waiting for input from a
socket and the sending process closes the socket, the select() notes
this as an exception rather than as data. Therefore, if the select()
is not currently looking for exceptions, it waits indefinitely.
However, my empirical testing disproves this. Specifically, if the
client process closes their end of the socket, select() returns that
read is no longer blocked, and if you recv() on it, it returns there
are no bytes to be consumed (thus you must be closed).
Now maybe select(, , errfds) is very implementation specific. I don't
have any problem using it, but I have no idea what to *do* with the
results.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk5 zVMQACgkQJdeBCY SNAAMNHACg2X/ pJ4ECkf3yxkTLRu 3b8zxM zSW4At71eYbzOBo 9t
FJQAn2eNvhRkXxL
=Y73m
-----END PGP SIGNATURE-----