> 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.


I think all you need is a single function. You pass it an SSL connection
and it returns to you a set of bits. One bit would mean that a read was
possible just from cached data, one bit would mean that a write is possible
if there is space in the socket buffer, one bit would mean that a write
cannot progress unless data is read from the socket and so on.

The function would be as light as possible, never doing any I/O, and just
checking what we know about the state of the SSL connection. Is data
buffered? Is negotiation in progress? Is the connection established? And so
on.

Basically, you just need to know, for both read and write directions,
whether the operation might complete immediately, needs to wait for data to
be read from the socket, or needs to wait for data to be written to the
socket.

You could easily implement the poll, select, and kevent semantics with just
this function. I can't think of any reason a more complex implementation
would be any better.

DS


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