On 10/8/2017 5:58 PM, Kyle Hamilton wrote:
Do you have a reference to what should be done instead? My understanding of what happens with blocking sockets is that SSL_read() will return SSL_ERROR_WANT_READ if it needs additional data read from a socket that doesn't have it available (and will return SSL_ERROR_WANT_WRITE if it needs to write for a handful of reasons, but can't). I had thought that the appropriate response would be to add that descriptor to the appropriate set to query on the next call to select(), and then call the same function with the same parameters so the library can advance its state machine. write() and read() have the means to tell you how much data was written or read, and that's what you're supposed to use to keep blocking descriptors from hanging your application, I thought. -Kyle H
With blocking sockets, you just loop back around and repeat the same call if either of those messages are returned by SSL_get_error(). No select() required.
Blocking operations will block (aka "hang") your application until the operation completes. If you don't want that to happen, then that's what non-blocking descriptors are for.
-- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
