OpenSSL implements asynchronous capabilities through an ASYNC_JOB. This
represents code that can be started and executes until some event occurs. At
that point the code can be paused and control returns to user code until some
subsequent event indicates that the job can be resumed.

The creation of an ASYNC_JOB is a relatively expensive operation. Therefore, for
efficiency reasons, jobs can be created up front and reused many times. They are
held in a pool until they are needed, at which point they are removed from the
pool, used, and then returned to the pool when the job completes. Before using
any of the asynchronous job functions, user code should first call
ASYNC_init(). If the user application is multi-threaded, then
ASYNC_init_thread() should be called for each thread that will initiate
asynchronous jobs. If the init_thread parameter to ASYNC_init() is non-zero
then ASYNC_init_thread is automatically called for the current thread. Before
user code exits it should free up resources for each thread that was initialised
using ASYNC_cleanup_thread(). No asynchronous jobs must be outstanding for the thread
when ASYNC_cleanup_thread() is called. Failing to ensure this will result in memory
leaks. Additionally an application should call ASYNC_cleanup() when all
asynchronous work is complete across all threads. If cleanupthread is
non-zero then ASYNC_cleanup_thread() is automatically called for the current
thread.

The max_size argument limits the number of ASYNC_JOBs that will be held in
the pool. If max_size is set to 0 then no upper limit is set. When an
ASYNC_JOB is needed but there are none available in the pool already then one
will be automatically created, as long as the total of ASYNC_JOBs managed by the
pool does not exceed max_size. When the pool is first initialised
init_size ASYNC_JOBs will be created immediately. If ASYNC_init_thread() is
not called before the pool is first used then it will be called automatically
with a max_size of 0 (no upper limit) and an init_size of 0 (no ASYNC_JOBs
created up front). If a pool is created in this way it must still be cleaned up
with an explicit call to ASYNC_cleanup_thread().

An asynchronous job is started by calling the ASYNC_start_job() function.
Initially *job should be NULL. ret should point to a location where the
return value of the asynchronous function should be stored on completion of the
job. func represents the function that should be started asynchronously. The
data pointed to by args and of size size will be copied and then passed as
an argument to func when the job starts. ASYNC_start_job will return one of
the following values:

ASYNC_ERR

An error occurred trying to start the job. Check the OpenSSL error queue (e.g.
see ERR_print_errors(3)) for more details.

ASYNC_NO_JOBS

There are no jobs currently available in the pool. This call can be retried
again at a later time.

ASYNC_PAUSE

The job was successfully started but was paused before it completed (see
ASYNC_pause_job() below). A handle to the job is placed in *job. Other work
can be performed (if desired) and the job restarted at a later time. To restart
a job call ASYNC_start_job() again passing the job handle in *job. The
func, args and size parameters will be ignored when restarting a job.
When restarting a job ASYNC_start_job()must be called from the same thread
that the job was originally started from.

ASYNC_FINISH

The job completed. *job will be NULL and the return value from func will
be placed in *ret.

At any one time there can be a maximum of one job actively running per thread
(you can have many that are paused). ASYNC_get_current_job() can be used to get
a pointer to the currently executing ASYNC_JOB. If no job is currently executing
then this will return NULL.

If executing within the context of a job (i.e. having been called directly or
indirectly by the function func passed as an argument to ASYNC_start_job())
then ASYNC_pause_job() will immediately return control to the calling
application with ASYNC_PAUSE returned from the ASYNC_start_job() call. A
subsequent call to ASYNC_start_job passing in the relevant ASYNC_JOB in the
*job parameter will resume execution from the ASYNC_pause_job() call. If
ASYNC_pause_job() is called whilst not within the context of a job then no
action is taken and ASYNC_pause_job() returns immediately.

Every ASYNC_JOB has a wait file descriptor associated with it. Calling
ASYNC_get_wait_fd() and passing in a pointer to an ASYNC_JOB in the job
parameter will return the wait file descriptor associated with that job. This
file descriptor can be used to signal that the job should be resumed.
Applications can wait for the file descriptor to be ready for read using a
system function call such as select or poll (being ready for read indicates
that the job should be resumed). Applications can signal that a job is ready to
resume using ASYNC_wake() or clear an existing signal using ASYNC_clear_wake().

An example of typical usage might be an async capable engine. User code would
initiate cryptographic operations. The engine would initiate those operations
asynchronously and then call ASYNC_pause_job() to return control to the user
code. The user code can then perform other tasks or wait for the job to be ready
by calling select or other similar function on the wait file descriptor. The
engine can signal to the user code that the job should be resumed using
ASYNC_wake(). Once resumed the engine would clear the wake signal by calling
ASYNC_clear_wake().

The ASYNC_block_pause() function will prevent the currently active job from
pausing. The block will remain in place until a subsequent call to
ASYNC_unblock_pause(). These functions can be nested, e.g. if you call
ASYNC_block_pause() twice then you must call ASYNC_unblock_pause() twice in
order to reenable pausing. If these functions are called while there is no
currently active job then they have no effect. This functionality can be useful
to avoid deadlock scenarios. For example during the execution of an ASYNC_JOB an
application acquires a lock. It then calls some cryptographic function which
invokes ASYNC_pause_job(). This returns control back to the code that created
the ASYNC_JOB. If that code then attempts to acquire the same lock before
resuming the original job then a deadlock can occur. By calling
ASYNC_block_pause() immediately after aquiring the lock and
ASYNC_unblock_pause() immediately before releasing it then this situation cannot
occur.