I'm trying to cope with OpenSSL's braindamaged nonblocking API (my coworkers and I tend to call it the "accidental programming interface") in a libevent application. The application handles a bidirectional data stream and, for simplicity's sake, maintains a small static buffer in each direction, counting on TCP to "double buffer" for decent performance.
The problem is that OpenSSL can require you to wait for write on the SSL fd in order to complete an SSL_read(). But the other side of our application (the other direction of the bidirectional datastream) may, itself, have just scheduled an SSL_write which also wants to wait for write, or can do so while we're still waiting for write in order to complete the SSL_read which triggered a rekeying of the session (and thus has us waiting on write on that fd already). Worse, OpenSSL imposes a requirement that the first operation in its API performed after an I/O operation returns wait-for-I/O be the exact same operation that triggered the wait condition (for example, if I do SSL_read() and get back SSL_ERROR_WANT_WRITE, the next operation I perform via the OpenSSL API on that direction of the SSL session _must_ be SSL_read() with the same target buffer and length). I see two ways to handle this. One is with very, very nasty application logic, and the other is to simply set two separate events with the SSL fd, each waiting on EV_WRITE. So when the SSL fd comes ready for write -- I'd hope -- both my pending SSL_read() and my pending SSL_write() would be invoked, each from a separate event's callback. Will that work, portably across underlying event mechanisms for libevent? Or is it possible that only one of the two callbacks will be called in some cases? Thor _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
