On 3/7/2011 4:19 PM, Yan, Bob wrote:
Thank you very much, David,
In general, if the application use "select/poll" system function to
> check the readable of underline BIO and invoke the SSL_read/SSL_write
> only if there are data available on the socket, can the deadlock still
> happened?
Not only can the deadlock I explained still happen, but many other
deadlocks can happen. The design you are talking about is the complete
opposite of how you correct use non-blocking sockets with OpenSSL.
You should call SSL_read/SSL_write any time you want to read or write to
or from the SSL connection. You should call a 'select' or 'poll'
function only when OpenSSL tells you to.
Specially, in your last statement "At step 3 above, the reader thread
is now blocking waiting for the renegotiation data to arrive on the
socket. But that renegotiation data has already been received and read
by the SSL engine.
So the thread will block indefinitely waiting for something that has > already happened.", the question is that if the
underline socket
is non-blocking and the
> application is using select/poll to check the readable of SSL
> connection and then > invoke the SSL_write/SSL_read call, can this
deadlock still happen?
Yes, that's precisely how the deadlock happens. It is easy to assume the
SSL connection has both a 'read state' and a 'write state' because TCP
connections do. But SSL does not. If 'SSL_write' returns WANT_READ, that
invalidates any prior WANT_READ condition you may have gotten from
'SSL_read' -- the SSL connection has one and only one state.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
