> Windows sends FD_WRITE event if writing is possible and previous > invokation of 'send' has failed with WSAEWOULDBLOCK code (only > this code, if it has failed from other reason, FD_WRITE will not > be send and waiting for it will cause deadlock)...
Let me try one more time: 1) The code changes I suggested *never* wait for an FD_WRITE. They wait for *any* change. 2) If a write was possible and stays possible, that is not a change. There are only two cases: 1) SSL_write failed because a write is not possible right now. In which case, it has to have called 'write' (or 'send') and gotten a WOULDBLOCK. Otherwise, how would it know? In this case, you will get an FD_WRITE indication. 2) SSL_write failed for some other reason. In this case, you will not get an FD_WRITE indication, but one wouldn't help you any way, since that's not the reason the write failed. Even if you got an FD_WRITE if a write was possible and you never got a WOULDBLOCK, your pseudo-code would still deadlock because SSL_write can fail because data needs to be read. Although it's technically true that a socket can change from unwriteable to writeable and you won't get an FD_WRITE event, this can only happen if a write didn't fail. If a write didn't fail, that means SSL wasn't attempting one anyway, so knowing it could now succeed won't let SSL make further progress. (How does knowing that something you weren't trying to do is possible help you?) I told you exactly how to fix your code -- never wait for just one thing. Rig your code so that you use the same event for *everything* that could possibly change. Unblock that event when you change something and make sure both FD_READ and FD_WRITE events wind up unblocking it. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
