From 05a6347fec744bd11ef94dd2ac9f68b4f679de8e Mon Sep 17 00:00:00 2001 From: Matt Caswell Date: Wed, 7 Oct 2015 10:00:22 +0100 Subject: [PATCH] Tweak async documentation based on feedback Add some clarifications to the async documentation. Also changed ASYNC_pause_job() so that it returns success if you are not within the context of a job. This is so that engines can be used either asynchronously or synchronously and can treat an error from ASYNC_pause_job() as a real error. Reviewed-by: Rich Salz --- CHANGES | 2 +- crypto/async/async.c | 6 +++--- doc/crypto/ASYNC_start_job.pod | 22 ++++++++++++++-------- doc/ssl/SSL_get_async_wait_fd.pod | 8 ++++---- doc/ssl/SSL_get_error.pod | 3 ++- 5 files changed, 24 insertions(+), 17 deletions(-) diff --git a/CHANGES b/CHANGES index b98ce7292e..6b501ee8c4 100644 --- a/CHANGES +++ b/CHANGES @@ -10,7 +10,7 @@ further details. Libssl has also had this capability integrated with the introduction of the new mode SSL_MODE_ASYNC and associated error SSL_ERROR_WANT_ASYNC. See the SSL_CTX_set_mode() and SSL_get_error() man - pages. + pages. This work was developed in partnership with Intel Corp. [Matt Caswell] *) State machine rewrite. The state machine code has been significantly diff --git a/crypto/async/async.c b/crypto/async/async.c index e0ff110e33..8fdff52d99 100644 --- a/crypto/async/async.c +++ b/crypto/async/async.c @@ -280,10 +280,10 @@ int ASYNC_pause_job(void) if(!async_get_ctx() || !async_get_ctx()->currjob) { /* - * Could be we've deliberately not been started within a job so we - * don't put an error on the error queue here. + * Could be we've deliberately not been started within a job so this is + * counted as success. */ - return 0; + return 1; } job = async_get_ctx()->currjob; diff --git a/doc/crypto/ASYNC_start_job.pod b/doc/crypto/ASYNC_start_job.pod index ec896340f8..6086260ff5 100644 --- a/doc/crypto/ASYNC_start_job.pod +++ b/doc/crypto/ASYNC_start_job.pod @@ -75,6 +75,8 @@ ASYNC_pause_job() below). A handle to the job is placed in B<*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 B<*job>. The B, B and B parameters will be ignored when restarting a job. +When restarting a job ASYNC_start_job() B be called from the same thread +that the job was originally started from. =item B @@ -83,8 +85,10 @@ be placed in B<*ret>. =back -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. +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()) @@ -99,9 +103,10 @@ 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 B 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 on the file descriptor using a system function call -such as select or poll. Applications can signal that a job is ready to resume -using ASYNC_wake() or clear an existing signal using ASYNC_clear_wake(). +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 @@ -109,7 +114,7 @@ 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_wait(). Once resumed the engine would clear the wake signal by calling +ASYNC_wake(). Once resumed the engine would clear the wake signal by calling ASYNC_clear_wake(). @@ -120,8 +125,9 @@ ASYNC_init_pool returns 1 on success or 0 otherwise. ASYNC_start_job returns one of ASYNC_ERR, ASYNC_NO_JOBS, ASYNC_PAUSE or ASYNC_FINISH as described above. -ASYNC_pause_job returns 0 if an error occured (including if called when not -within the context of an ASYNC_JOB), or 1 on success. +ASYNC_pause_job returns 0 if an error occured or 1 on success. If called when +not within the context of an ASYNC_JOB then this is counted as success so 1 is +returned. ASYNC_get_wait_fd returns the "wait" file descriptor associated with the ASYNC_JOB provided as an argument. diff --git a/doc/ssl/SSL_get_async_wait_fd.pod b/doc/ssl/SSL_get_async_wait_fd.pod index da7617b2de..840c9c886e 100644 --- a/doc/ssl/SSL_get_async_wait_fd.pod +++ b/doc/ssl/SSL_get_async_wait_fd.pod @@ -20,10 +20,10 @@ L). SSL_get_async_wait_fd() returns a file descriptor which can be used in a call to select() or poll() to determine whether the current asynchronous operation has completed or not. A completed operation will result in data appearing as -available on the file descriptor (no actual data should be read from the file -descriptor). This function should only be called if the SSL object is currently -waiting for asynchronous work to complete (i.e. SSL_ERROR_WANT_ASYNC has been -received - see L). +"read ready" on the file descriptor (no actual data should be read from the +file descriptor). This function should only be called if the SSL object is +currently waiting for asynchronous work to complete (i.e. SSL_ERROR_WANT_ASYNC +has been received - see L). =head1 RETURN VALUES diff --git a/doc/ssl/SSL_get_error.pod b/doc/ssl/SSL_get_error.pod index d950fa3ed9..271f849666 100644 --- a/doc/ssl/SSL_get_error.pod +++ b/doc/ssl/SSL_get_error.pod @@ -96,7 +96,8 @@ engine is being used. An application can determine whether the engine has completed its processing using select() or poll() on the asynchronous wait file descriptor. This file descriptor is available by calling L. The TLS/SSL I/O function should be called again -later. +later. The function B be called from the same thread that the original +call was made from. =item SSL_ERROR_SYSCALL -- GitLab