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

[Adam Olsen]

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