[Python-3000] Non-blocking I/O? (Draft PEP for New IO system) (original) (raw)

Adam Olsen rhamph at gmail.com
Mon Mar 5 03:54:06 CET 2007

On 3/4/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

I'm having trouble seeing what the use case is for the buffered non-blocking writes being discussed here.

Doing asynchronous I/O usually doesn't involve putting the file descriptor into non-blocking mode. Instead you use select() or equivalent, and only try to read or write when the file is reported as being ready.

I can't say which is more common, but non-blocking has a safer feel. Normal code would be select-driven in both, but if you screw up with non-blocking you get an error, whereas blocking you get a mysterious hang.

accept() is the exception. It's possible for a connection to disappear between the time select() returns and the time you call accept(), so you need to be non-blocking to avoid hanging.

For this to work properly, the select() needs to operate at the bottom of the I/O stack. Any buffering layers sit above that, with requests for data propagating up the stack as the file becomes ready. In other words, the whole thing has to have the control flow inverted and work in "pull" mode rather than "push" mode. It's hard to see how this could fit into the model as a minor variation on how writes are done.

Meaning it needs to be a distinct interface and explicitly designed as such.

-- Adam Olsen, aka Rhamphoryncus

More information about the Python-3000 mailing list