> On 4/15/07, David Schwartz <[EMAIL PROTECTED]> wrote: > > 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.
> One reason, as suggested by Thor, is that OpenSSL sometimes needs to > wait on more complex events than just socket read or write. In > particular, some hardware appears to require the use of kevent to > signal completion of crypto operations. It seems fairly natural, > then, to express these wait predicates in terms of a struct kevent. > > Nickolai. The problem is that 'kevent' is a platform-specific construct. Basing the API on it would mean that portable programs couldn't use the API. I think a better solution is to require unusual things to make themselves appear normal rather than forcing normal things to make themselves unusual. Worst case, you can create a thread to wait for kevents and write a byte to a pipe when they occur. I have no objection to a 'kevent' based API for 'kevent' based programs. But more typical programs based around 'poll' should have access to such an API as well. Heck, all types of programs could take advantage of an asynchronous status-reporting type function. However, you are correct that the API I suggested is too simple to account for this. For example, even if did create a thread that wrote to a pipe when the operation was ready to make forward progress, there would be no way to tell the application which socket to add to its poll set. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
