The joys and jilts of non-blocking sockets

Panu A Kalliokoski pkalliok at
Thu May 31 11:13:32 CEST 2001

Robert Amesz <rcameszREMOVETHIS at> 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 

I'd say non-blocking sockets are easier to use than blocking ones, but
usually you don't need them for anything. The only problems with 
non-blocking sockets are that they can give you interesting error codes 
that you have to take action on, and the errors returned vary from 
platform to platform. Usually, the right solution is to use select() with 
possible timeouts, not non-blocking sockets. That's why I've made the 
selecting package (

Non-blocking sockets only make sense if you have a background task which 
you want to accomplish while listening to the sockets. For this special 
case, threads are better suited.

> documentation isn't really too helpful here. I feel this is a mistake: 
> without documentation people like me will experiment to find out how 

I'm not really one of the Python people, but I know the issues on the 
socket API are more of OS than language information. The socket 
abstraction in Python (at least when I was using it) is not nearly a good 
one. Maybe that should be corrected. Anyway, good information on sockets 
can be found all over the net and from the Un*x manual (man 2 socket, man 
4 socket).

I hope not every language project would have to make new socket tutorials, 
as the situation is now. That's a lot of added, overlapping work.

> I've also studied 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.

Please have a look at the asyncore package (distributed with Python) and 
selecting (a pointer to which I gave above).

Panu Kalliokoski

More information about the Python-list mailing list