> Right. This means that it is *not* safe to just wait for an event. You have > to try the operation first, and only wait for the event if you know that you > need to wait for the event. > > Retry the write anytime anything changes. Only wait for an event if you can > make no further progress unless the event occurs.
> I'm not sure specifically what your problem is. Instead of calling 'select' > and then trying the write, just try the write. If it fails, retry it when > anything changes (that would include a successful read or any kind of event). > That is the simplest way. > But,this is the way i'm currently do it !!! Sorry but I think that you really don't understand... I'm not checking socket's possibility to write, i'm just issuing SSL_write command till SSL_write will return SSL_ERROR_WANT_WRITE. Now, what? On unix i can use 'select' with socket handle as input in write set. It will return when writing will become possible. But on windows it's not such easy... Please, here you have fragment from windows help: "...The FD_WRITE network event is handled slightly differently. An FD_WRITE network event is recorded when a socket is first connected with connect/WSAConnect or accepted with accept/WSAAccept, and then after a send fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE network event setting and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will find out that sends are again possible when an FD_WRITE network event is recorded and the associated event object is set...." it means that that i can issue 'send' commands till it will return WSAEWOULDBLOCK, then i can safely assiociate FD_WRITE option with my event object and wait in 'WaitForMultipleObjects' till windows will signal this event.(writing will become again possible). But i'm not using native winsocks API, i'm using openSSL. OpenSSL issues 'sends' commands internally. When i issue SSL_write, i don't known how many times openSSL issues 'send' command and what is return value of 'send'. The only thing i will get is SSL_ERROR_WANT_WRITE. (It could, but it don't have to (!!!!) be result of WSAEWOULDBLOCK 'send' error, it could be result of other errors or some openSSL internal logic). See: 'BIO_sock_non_fatal_error' function in 'bss_sock.c' in openSSL source tree. In simply words: 'select' returns current possibility of socket to do something, windows events are results of some other events not current socket's states. I cannot simply wait for some condition to become possible i should know if i have to wait, openSSL breaks this logic: it doesn't do everything not bothering user, but it also takes away control from user over issuing winsock commands. I have an idea (now just only idea) of how it could be overcome but this is my own idea and i have to test it (mix windows events with 'select' in some special way). But what is the sense of sending questions i answer to it my own? I think OpenSSL is not such windows compatibile as it's advertised to be. > The beauty of non-blocking operations is it's perfectly safe to retry every > operation anytime anything changes. So you have to do something really dumb > to deadlock. > No comments. Lucas ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
