On 9/15/2011 2:46 AM, Martin Pool wrote:
> On 13 September 2011 23:23, John A Meinel <email address hidden>
> wrote:
>> select([c], [], [], 10.0) in terminal A and s.close() in
>> terminal B will cause select to return before the timeout, and
>> s.recv() to return the empty string. Is this a
>> 'not-guaranteed-but-likely' behaviour?
>
> You very likely want to select on c for errors as well as
> readability (ie put it in the third list.)
>
> If the remote end closes while select is waiting I think you are
> guaranteed to get that behaviour - select will return communicating
> "you can read" and then what you actually read is an EOF.
Right, it is even documented as such.
What errors could we get, so I can write a test case for it?
>
>> AFAICT, even though the socket is set to blocking mode,
>> sock.recv() is
> returning an empty string, but select(sock) is not returning to
> indicate the socket has bytes/is closed.
>
> I wonder if this is a race where the eof arrives before you do the
> select? I can't remember if that can actually happen.
>
It seems that it is happening after we start select.select() and then
the *local* socket is getting closed by the test suite teardown code.
After which, select doesn't trigger 'closed'. If you run select again,
you actually get EBADF.
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/15/2011 2:46 AM, Martin Pool wrote: -but-likely' behaviour?
> On 13 September 2011 23:23, John A Meinel <email address hidden>
> wrote:
>> select([c], [], [], 10.0) in terminal A and s.close() in
>> terminal B will cause select to return before the timeout, and
>> s.recv() to return the empty string. Is this a
>> 'not-guaranteed
>
> You very likely want to select on c for errors as well as
> readability (ie put it in the third list.)
>
> If the remote end closes while select is waiting I think you are
> guaranteed to get that behaviour - select will return communicating
> "you can read" and then what you actually read is an EOF.
Right, it is even documented as such.
What errors could we get, so I can write a test case for it?
>
>> AFAICT, even though the socket is set to blocking mode,
>> sock.recv() is
> returning an empty string, but select(sock) is not returning to
> indicate the socket has bytes/is closed.
>
> I wonder if this is a race where the eof arrives before you do the
> select? I can't remember if that can actually happen.
>
It seems that it is happening after we start select.select() and then
the *local* socket is getting closed by the test suite teardown code.
After which, select doesn't trigger 'closed'. If you run select again,
you actually get EBADF.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk5 yeIAACgkQJdeBCY SNAAM+vACggkQ68 F7RVTuDAopKmdg0 23dQ oYCq+ywMCzHtBVO 0eAe
dDoAnj45SEjw+
=0dqR
-----END PGP SIGNATURE-----