Bill Janssen added the comment: "You seem to be missing the whole point of doing non-blocking I/O,"
You know, I think that's right. I'm so used to using threads by now that the whole select-based approach seems very odd to me by now. OK, I've folded your patch into the PyPI version, ssl 1.8. It will meander into the trunk and 3K version as well. Thanks for the help! Bill On 10/15/07, Chris Stawarz <[EMAIL PROTECTED]> wrote: > > Chris Stawarz added the comment: > > Bill, > > You seem to be missing the whole point of doing non-blocking I/O, > which is to handle multiple concurrent, I/O-bound tasks in a single > OS thread. The application must be able to try the handshake, detect > that it didn't complete because I/O needs to take place, and then > retry it at a later time of its choosing (presumably when select() > says it's OK to read from the socket). And between now and that > later time, it can do other things, like read or write to other sockets. > > The point is that the *application* must have control over when it > does I/O, when it waits for sockets to be ready for I/O, and what it > does in between. There's just no way it can do this if the sslwrap() > function doesn't return until the handshaking is complete. sslwrap() > can't "do the right thing", because the right thing is to return > control to the application until it's ready to try the handshake again. > > And this has nothing to do with the GIL or multiple threads. Like I > said, the point of doing non-blocking I/O with select() is to *avoid* > the need for multiple threads. > > __________________________________ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1251> > __________________________________ > __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
