On Sun, Mar 02, 2008 at 11:04:18PM -0500, Geoff Thorpe wrote: > Hi Thor, > > I'm slowly coming back through a few tonnes of spooled email that has > been accumulating for months (including everything openssl-related). > That's just some context. I may have missed prior discussion about all > sorts of things related to ENGINE and async requirements, if so my > apologies. > > FWIW, this is not really the right way of implementing async support in > openssl. "Completion" events are not always going to be related to file > descriptors in any clear way
Certainly if the file in question is one for a Unix device driver, and that device driver is in use for asynchronous hardware-accellerated crypto operations, there will, in fact, be a perfectly clear relationship. I don't care, call it an "ENGINE-specified opaque token" if you like; but you must be able to completion-wait on it without using threads and condition variables, or it won't be useful to many users of the existing non-blocking mode of the OpenSSL API. If you can't get the resource to wait on, or can't wait on it with select() or poll() -- then you cannot do asynchronous crypto. > , and besides which the SSL/TLS stack in > openssl is not really one where you'd want to try and implement "resume" > semantics. Ie. the "call the exact same thing again" approach sounds > like the SSL/TLS objects get left in a "limbo" state after an > asynchronous operation has started - I think I understand why you've > done things this way We did it this way because it is *precisely what OpenSSL already requires for any asynchronous operation that returns before completion already*. There is no net change in semantics (these semantics are *already* required in the case where the underlying network transport is non-blocking; you must select for read or write per the WANT_READ or WANT_WRITE error return at the SSL layer, but the next SSL operation you must issue is required to be the exact same one you issued previously) merely an observation on my part that those semantics are...perhaps not what I myself would have designed. Yes, the semantics are gory -- but they are already in place. Sorry if I caused confusion on this point; I meant only to add a new error code (WANT_CRYPTO in addition to the existing WANT_READ and WANT_WRITE) which would indicate the existing semantics re retrying operations are required (but to add an additional file descriptor to the select set), not change the whole mechanism. Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
