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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
