If application uses any of Windows-specific interfaces, make it
application developer's respondibility to include <windows.h>.
Rationale is that <windows.h> is quite "toxic" and is sensitive
to inclusion order (most notably in relation to <winsock2.h>).
It's only natural to give complete control to the application developer.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Implementation experience has shown that the original plan for async wait
fds was too simplistic. Originally the async logic created a pipe internally
and user/engine code could then get access to it via API calls. It is more
flexible if the engine is able to create its own fd and provide it to the
async code.
Another issue is that there can be a lot of churn in the fd value within
the context of (say) a single SSL connection leading to continually adding
and removing fds from (say) epoll. It is better if we can provide some
stability of the fd value across a whole SSL connection. This is
problematic because an engine has no concept of an SSL connection.
This commit refactors things to introduce an ASYNC_WAIT_CTX which acts as a
proxy for an SSL connection down at the engine layer.
Reviewed-by: Richard Levitte <levitte@openssl.org>
This was done by the following
find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
print unless $. == 1 && m@/\* .*\.[ch] \*/@;
close ARGV if eof; # Close file to reset $.
And then some hand-editing of other files.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Applications wishing to include their own stacks now just need to include
DEFINE_STACK_OF(foo)
in a header file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
In the async code for MacOS/X define _XOPEN_SOURCE (if not already
defined) as early as possible. We must do this before including
any header files, because on MacOS/X <stlib.h> includes <signal.h>
which includes <ucontext.h>. If we delay defining _XOPEN_SOURCE
and include <ucontext.h> after various system headers are included,
we are very likely to end up with the wrong (truncated) definition
of ucontext_t.
Also, better error handling and some code cleanup in POSIX fibre
construction and destruction. We make sure that async_fibre_makecontext()
always initializes the fibre to a state that can be freed.
For all implementations, check for error returns from
async_fibre_makecontext().
Reviewed-by: Matt Caswell <matt@openssl.org>
Implements Thread Local Storage in the windows async port. This also has
some knock on effects to the posix and null implementations.
Reviewed-by: Rich Salz <rsalz@openssl.org>
In theory the pthreads approach for Thread Local Storage should be more
portable.
This also changes some APIs in order to accommodate this change. In
particular ASYNC_init_pool is renamed ASYNC_init_thread and
ASYNC_free_pool is renamed ASYNC_cleanup_thread. Also introduced ASYNC_init
and ASYNC_cleanup.
Reviewed-by: Rich Salz <rsalz@openssl.org>
A lot of the pool handling code was in the arch specific files, but was
actually boiler plate and the same across the implementations. This commit
moves as much code as possible out of the arch specific files.
Reviewed-by: Rich Salz <rsalz@openssl.org>
We were using _pipe to create a pipe on windows. This uses the "int" type
for its file descriptor for compatibility. However most windows functions
expect to use a "HANDLE". Probably we could get away with just casting but
it seems more robust to use the proper type and main stream windows
functions.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There are potential deadlock situations that can occur if code executing
within the context of a job aquires a lock, and then pauses the job. This
adds an ability to temporarily block pauses from occuring whilst performing
work and holding a lock.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Initial API implemented for notifying applications that an ASYNC_JOB
has completed. Currently only s_server is using this. The Dummy Async
engine "cheats" in that it notifies that it has completed *before* it
pauses the job. A normal async engine would not do that.
Only the posix version of this has been implemented so far, so it will
probably fail to compile on Windows at the moment.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Create a "null" async implementation for platforms that lack support. This
just does nothing when called and therefore performs synchronously.
Reviewed-by: Rich Salz <rsalz@openssl.org>
