Author chris.stawarz
Recipients chris.stawarz, janssen
Date 2007-10-16.00:11:30
SpamBayes Score 0.0496742
Marked as misclassified No
Message-id <DBFC07DD-A8AE-4632-8615-1A938D631665@csail.mit.edu>
In-reply-to <1192470789.62.0.851906749518.issue1251@psf.upfronthosting.co.za>
Content
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.
History
Date User Action Args
2007-10-16 00:11:31chris.stawarzsetspambayes_score: 0.0496742 -> 0.0496742
recipients: + chris.stawarz, janssen
2007-10-16 00:11:31chris.stawarzlinkissue1251 messages
2007-10-16 00:11:30chris.stawarzcreate