> Did you look at my logs with s_client? I'm starting to suspect that the > correct way to put it is: "there is *spposed* to be no deadlock, > but there > is a bug in SSL_read that can make you screwed".
The bug is not in SSL_read. The bug is in the decision to call SSL_read. There is one important difference between SSL and TCP. A 'select' hit on TCP guarantees (almost) that there is application-level data to read, so you can generally get away with following a 'select' hit for read with a blocking read. However, a 'select' hit on an SSL connection does not in any way guarantee that there is application-level data to read, so it is an error to call a blocking read function based solely on a 'select' hit. For SSL, you can only call a blocking SSL_read if you know from the application-level protocol that it is safe to block until application-level data is received. (Just as would be the case with calling 'read' on a TCP connection *without* a select.) The error is in assuming that read hit from 'select' guarantees that there is application-level data and therefore that it's safe to call an application-level blocking read function. A read hit from 'select' is *NOT* justification for calling a blocking SSL_read function. Only knowledge that it is safe to block until application-level data is received will do. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]