Under the new design, picotls supplies jobs and weak references to ptls_t associated to each job. It is up to the user to run those jobs. Once the job is complete, the user calls ptls_handshake if the weak reference is still valid. Otherwise, resources are reclaimed automatically.
The upside of the design is that the API (ptls_openssl_async_runner_t) is agnostic of the type of the job. At the moment only RSA signature generation is offloaded, but we have the opportunity to offload other stuff without changing the API.
The downside is that each user has to implement their own job handling code (e.g., call ASYNC_start_job). Though, it might be possible to argue that the design is simpler and easier to understand because picotls does not abstract how OpenSSL runs async jobs.
For more information, please refer to the definition of ptls_openssl_async_runner_t (found here) as well the async code is t/openssl.c.
Under the new design, picotls supplies jobs and weak references to
ptls_tassociated to each job. It is up to the user to run those jobs. Once the job is complete, the user callsptls_handshakeif the weak reference is still valid. Otherwise, resources are reclaimed automatically.The upside of the design is that the API (
ptls_openssl_async_runner_t) is agnostic of the type of the job. At the moment only RSA signature generation is offloaded, but we have the opportunity to offload other stuff without changing the API.The downside is that each user has to implement their own job handling code (e.g., call
ASYNC_start_job). Though, it might be possible to argue that the design is simpler and easier to understand because picotls does not abstract how OpenSSL runs async jobs.For more information, please refer to the definition of
ptls_openssl_async_runner_t(found here) as well the async code is t/openssl.c.