select.select and socket.setblocking

Francesco Bochicchio bockman at virgilio.it
Wed Dec 31 10:20:47 CET 2008


Jean-Paul Calderone ha scritto:
> On Tue, 30 Dec 2008 19:19:08 +0100, Francesco Bochicchio 
> <bockman at virgilio.it> wrote:
>> [snip]
>>
>> If you are interested in socket errors, you should
>> also fill the third 'fd-set' in the select call, and after select 
>> returns check that fd is not in it anymore:
>>
>> ready = select.select( [fd],[], [fd] )
>> if fd in ready[2]:
>>    # raise your error here
> 
> The third argument to select() isn't for monitoring sockets for errors.  
> Its
> behavior is also rather platform sensitive.  In general, you don't need it
> at all on POSIX, but on Windows you should pass the same list for it as you
> pass for the write-set, merge the results, and treat them all as writeable.
> 
> Or use a higher-level library that deals with all the asinine details for
> you. ;)
> 
> Jean-Paul

Yes, now that you mention it I remember having to do something like that 
on a socket library I wrote on windows ... IIRC, the send could not 
complete and then signal the readyness of the socket through
the third argument of the select ...

My experience is mostly on unices, and I usually don't use  the third 
argument (and not often the second)  but I remember having read on 
select manual page that it was  for errors. Now both python manuals
than select manual page say it is for 'exceptional conditions', without
going into details ...

Tx for the clarification, anyway ...

Ciao
----
FB



More information about the Python-list mailing list