> It works good (for unencrypted sockets of course) but > unfortunately in another way then someone may think. 'select' > statement returns immediately when desired condition is met - for > example you are waiting for some data to arrive and this data > arrives 'select' returns, if you will not read this data and you > will invoke 'select' again it returns immediately because there > is still data to read. The same is for write. 'select' returns if > there is possibility to send data.
Right. This means that it is safe to call 'select' and then try the operation only if 'select' tells you to. > For windows events it works > like this: Thread is waiting for read condition to be met - for > example it is waiting for some data to arrive. Data arrives, and > thread weaks up. It signals that there is some data, but if you > will not read this data and You will decide > to wait again thread will not wake up !!! Windows supposes that > you were noticed about some event and there is no need to notice > you again. 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. > For write event it is much worst. Windows supposes > that you can always write to socket and only when some special > error occurs (WSAEWOULDBLOCK) it signals possibility to write > when problem disappears. In practice it is more complicated, > socket functions (send,recv) change internally some states. > It is written in windows help files how it works (check MSDN for > detailed explanation). > It works good if you have control over issued commands. But if > you are using third party components like openSSL which use some > functions internally (recv,send) it is very complicated to > predict behaviour of code. For example if return value from > SSL_write is SSL_ERROR_WANT_WRITE > what should I do? if SSL_write failed because send(used > internally by openSSL) has returned WSAEWOULDBLOCK then I can > wait for FD_WRITE condition to be met, but if it has failed from > another reason waiting function will block.... I don't known > which socket functions are issued by openSSL command, how many > times and what are the error codes. Retry the write anytime anything changes. Only wait for an event if you can make no further progress unless the event occurs. > It,s ill, really ill..... I have no force to write.... > (I have some idea how it could be done (mix wit 'select') but > first i try to ask someone) > David, do you have any reference example how it should be done in > windows environment??? 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. If you want to be more sophisticated, you can look at the specific WANT errors. If you get WANT_WRITE, then the operation will not be possible until OpenSSL can write, so you can safely wait for a write event (or error/close). If you get WANT_READ, then the operation will not be possible until OpenSSL can read, so you can safely wait for a read event. 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. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
