On Sat, Apr 14, 2007 at 02:27:42PM -0700, Nickolai Zeldovich wrote: > > Composability may be a desirable property for any asynchronous OpenSSL > interface. Currently, it's possible to run OpenSSL with other > event-based libraries in the same thread, by calling select() on the > union of file descriptors from all libraries.
Not really: right now, SSL can effectively block you for as long as it likes and there's nothing you can do about it. This makes writing real event-driven applications with OpenSSL a non-starter. > One alternative would be to provide a function (say, > SSL_select_prepare) that would be called before the application code > calls select(), which would set the appropriate bits in the > caller-supplied fd_sets for SSL connections of interest to the > application. This is a good idea. But what if what SSL actually needs to do in order to wait on the fds you're interested in, plus the cryptographic operations for your SSL contexts, is considerably more than just adding fds to a select set? For example, in the vendor-supplied code I maintain, the only really practical way to wait on all the right things efficiently will be to transform the supplied select set or pollfds into a kevent structure, add a number of kevent elements specific to the hardware device, and wait for notifications. I could massage the underlying code to wait on the device's fd with poll() instead, but then I would still need to do a second system call to get cryptographic results, then handle them internally, before I could guarantee that a user's SSL_read() or _write() would actually return useful results. Basically, to run efficiently with hardware crypto, you really want the call that waits on events to happen _in_ OpenSSL. If you just cause stuff to be added to the application's wait set and let it do the waiting call, you can't actually consume crypto-done and return control to the application in an efficient way. And consumers of this interface likely really, really care about efficiency, since if they were willing to take the hit associated with context-switches for threading (15% on my device at saturation with 4K SSL connections) they'd just avoid the issue by using threads. :-/ Still, right now there is _no_ way to do this. Anything reasonably clean, it seems to be, is better than that! Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
