On 4/14/07, Thor Lancelot Simon <[EMAIL PROTECTED]> 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. Nickolai. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
