As a maintainer of libevent, and spending heaps of time in the ssl abstractions, anything to remove all the insane things you must do now for async io would be a reprieve of the horrors we've dealt with over the years.
I do worry that these patches may take too much of the work away to the point of no decent control mechanism. When I see poll() everywhere, it throws up red flags. I will spend some time with the proposed patches here, and see if I can make libevent happy, and hopefully very less complex. Fingers crossed. Cheers! On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell <m...@openssl.org> wrote: > > > On 07/10/15 14:29, Viktor Dukhovni wrote: > > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote: > > > >> I have also added async support to s_server and s_client through the new > >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an > >> effect you will obviously also need an async engine (such as dasync) > >> loaded through the "-engine" flag. Note that dasync will only be loaded > >> dynamically and thus OpenSSL must be built "shared" for this to work. > >> > >> Documentation including some example code is available on all of this > here: > >> > https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod > >> > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod > >> > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod > >> > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod > >> > >> I'd be interested to hear your thoughts. > > > > Will existing applications doing non-blocking I/O with OpenSSL need > > to be modified to handle SSL_ERROR_WANT_ASYNC? Or does that happen > > only if they explicitly request "async mode"? > > No, they should not need to be modified. You will only get > SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC. > > > > > Should applications generally enable async mode because that might > > be beneficial down the road? Or is this just for exotic hardware > > not likely to be seen in most environments? > > It will only be helpful if you have an engine capable of supporting > async. I can't really answer the question because I don't know how > common this will be. My hope is that this will become relatively common. > I have been toying with the idea of creating a multi-threaded async > engine where the engine manages a pool of threads to offload async work > to which would then offer true async support even if you don't have > specialist hardware. > > > For example, should Postfix enable "async" support? It does timed > > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}. > > If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is > not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I > would encourage making the changes. You may want to consider making it a > configurable option. There is a small overhead with creating ASYNC_JOBs > and context switching into them when they start and finish. > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
