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 nee
Chris Stawarz added the comment:
> The loop in _ssl.c/do_handshake will never return WANT_READ or
> WANT_WRITE, so the loop in the test case, for instance, is
> unnecessary.
I don't know why you think that, but it's easy enough to show that
this statement is incorrect.
Chris Stawarz added the comment:
I meant that SSL-wrapped sockets must be set non-blocking in the case
where you want to do non-blocking I/O with them using select(). This
is another difference between SSL-wrapped sockets and normal
sockets. With a normal socket, as long as you use
Chris Stawarz added the comment:
Yeah, the pattern for doing non-blocking I/O with select() is
different for SSL-wrapped sockets: You always have to try the
potentially-blocking operation first, and then call select() and
retry in response to SSL_ERROR_WANT_READ/WRITE. (You can also
New submission from Chris Stawarz:
The current version of the ssl module doesn't support non-blocking
creation of SSLSocket objects. The reason for this is that the SSL
handshaking (SSL_connect/SSL_accept) takes place during the
construction of the SSLContext object (in newPySSLObject).
