On Fri, May 29, 2020 at 06:35:58PM -0400, Watson Ladd wrote: > In my experience the issues are thorniest when dealing with blocking > sockets. Libraries using nonblocking sockets have to signal to the > application that they want IO to happen during the handshake, and can > use that same mechanism at later times, particularly for rekeying. > Libraries with blocking behavior are unfortunately in a difficult > position if they imitate a POSIX API and have no means to drive I/O. > > One possible dirty trick is to set nonblocking on an owned socket and > translate the blocking call into a select or poll based loop that > issues both writes and reads until enough is read or written. Note > that the real corner case is unanticipated needs to read from the > socket: the library has control when it needs to write.
Indeed. Another is to start a worker thread to do all (async) I/O on the connection and use inter-thread communications primitives on the blocking I/O API side. Because the worker thread needs to do async I/O anyways, it might as well service multiple connections to reduce the amount of resources needed for the whole thing. Nico -- _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
