The joys and jilts of non-blocking sockets

[Steve Holden]

"Robert Amesz" <rcameszREMOVETHIS at dds.removethistoo.nl> wrote ...
> I've recently been doing a little work with sockets, more in particular
> non-blocking sockets, and I'm sorry to say the standard Python
> documentation isn't really too helpful here. I feel this is a mistake:
> without documentation people like me will experiment to find out how
> things work, and we may end up relying on features which are either
> different for different platforms, or not guaranteed to work with
> different versions of Python, or both. This is not good. I've
> documented my experiments in the hope that will be useful to others and
> also to elicit some comments, in particular where other platforms or
> versions of Python are concerned.
>
Non-blocking sockets certainly aren't easy. The best use I've seen is Sam
Rushing's (and now the standard library's) asyncore and astnchat modules.
They probably do what you need.

> I've also studied timeoutsocket.py for some hints and pointers about
> socket behaviour, and this is a good source of information about some
> of the quirks of non-blocking sockets, so I'd like to thank
> Timothy O'Malley for that.
>
> Even so I'd like to take the opportunity to point out a few bugs and a
> design flaw in version 1.15 (the latest version I was able to find).
> One of the bugs is/are a set of missing commas in lines 142, 143, 144
> and 147: without those commas tuples aren't tuples, I'm afraid. (My
> guess is those were lists originally.)
>
> The other, slightly larger bug is that error code 10022 (in
> TimeoutSocket.connect()) is taken as an indication that the connection
> has been made, while in fact the connection has been refused (see below
> for more details about that).
>
Tim doesn't have a Windows machine to test on, and so he relies on bug
reports from Windows users. Please let him have a copy of this mail if you
didn't already.

> The design flaw is that the module makes non-blocking sockets behave
> like blocking ones: this just doesn't make sense to me. Arguably, using
> both types of sockets in a single application shouldn't be too common,
> but as it - very cleverly - replaces the normal socket-module once
> imported, it really should handle the non-blocking case too. Not that
> it's hard: in fact, it's almost trivial, but it should be done.
>
[ ... ]

regards
 Steve