Greg Ewing wrote:

Antoine Pitrou wrote:

...

For starters, since py3k is supposed to support non-blocking IO, why not write a portable API to make a raw file or socket IO object non-blocking?

I think we need to be clearer what we mean when we talk about non-blocking in this context. Normally when you're using select/poll you *don't* make the underlying file descriptor non-blocking in the OS sense. The non-blockingness comes from the fact that you're using select/poll to make sure the fd is ready before you access it.

So I don't think it makes sense to talk about having a non-blocking API as a separate thing from a select/poll wrapper. The select/poll wrapper *is* the non-blocking API.

This is not necessarily the case. In fact, modern sources often recommend using poll along with the non-blocking sockets for (among other things) performance reasons. For example, when a non-blocking socket becomes readable, you don't read from it only once and go back to the event loop, you read from it in a loop until you get EAGAIN. This allows for processing of fast-incoming data with fewer system calls. Linux's select(2) man page includes a similar advice with different motivation: Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block. Even if you don't agree that using O_NONBLOCK with select/poll is the best approach to non-blocking, I think there is enough existing practice of doing this to warrant separate consideration of non-blocking sockets (in the OS sense) and select/poll.