On 3/4/07, Greg Ewing <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
