On 4/14/07, Thor Lancelot Simon wrote:
> 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.

If kevents are the only direct asynchronous notification mechanism for
this hardware, then it doesn't seem unreasonable to require the
application to use kevent() for high performance. OpenSSL could
provide a function to return the set of (struct kevent)s for a given
SSL connection, which would be EV_ADD'ed by the application code.
When these kevents become pending, the application code would invoke
an OpenSSL callback to process them (e.g. kevent->udata could contain
the address of the callback function). Lacking kevents, OpenSSL could
fall back to synchronous handling of this hardware, as there is no
other notification mechanism.

This approach lets an application, if necessary, to queue other
kevents and handle them at the same time (e.g. because it wants to run
another library, similar to OpenSSL, in the same thread), or even
translate the kevents provided by OpenSSL into some newer notification
mechanism that may become available in the future.

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org