summaryrefslogtreecommitdiffstats
path: root/crypto/threads_win.c
AgeCommit message (Collapse)Author
2016-11-14Revert "Fixed deadlock in CRYPTO_THREAD_run_once for Windows"Matt Caswell
This reverts commit edc18749bd5dfb7e12513d3978f78f9b56104fd6. The proposed fix is incorrect. It marks the "run_once" code as having finished before it has. The intended semantics of run_once is that no threads should proceed until the code has run exactly once. With this change the "second" thread will think the run_once code has already been run and will continue, even though it is still in progress. This could result in a crash or other incorrect behaviour. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-11-13Fixed deadlock in CRYPTO_THREAD_run_once for WindowsDK
Fixed deadlock in CRYPTO_THREAD_run_once() if call to init() is causing a recursive call to CRYPTO_THREAD_run_once() again that is causing a hot deadloop inside do { } while (result == ONCE_ININIT); section. CLA: trivial Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1913) (cherry picked from commit 349d1cfddcfa33d352240582a3803f2eba39d9a0)
2016-07-08include/openssl: don't include <windows.h> in public headers.Andy Polyakov
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>
2016-05-20Fix Windows 64 bit crashesMatt Caswell
The function InitOnceExceuteOnce is the best way to support the implementation of CRYPTO_THREAD_run_once() on Windows. Unfortunately WinXP doesn't have it. To get around that we had two different implementations: one for WinXP and one for later versions. Which one was used was based on the value of _WIN32_WINNT. This approach was starting to cause problems though because other parts of OpenSSL assume _WIN32_WINNT is going to be 0x0501 and crashes were occurring dependant on include file ordering. In addition a conditional based on _WIN32_WINNT had made its way into a public header file through commit 5c4328f. This is problematic because the value of this macro can vary between OpenSSL build time and application build time. The simplest solution to this mess is just to always use the WinXP version of CRYPTO_THREAD_run_once(). Its perhaps slightly sub-optimal but probably not noticably. GitHub Issue #1086 Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-17Copyright consolidation 05/10Rich Salz
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-16Fold threads.h into crypto.h making API publicViktor Dukhovni
Document thread-safe lock creation Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-02Fix: CRYPTO_THREAD_run_onceMat
InitOnceExecuteOnce returns nonzero on success: MSDN: "If the function succeeds, the return value is nonzero." So return 1 if it is nonzero, 0 others. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09Fix return type for CRYPTO_THREAD_run_onceMat
return type should be int and not void Signed-off-by: Rich Salz <rsalz@akamai.com> Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-03GH773: Possible leak on CRYPTO_THREAD_lock_new failureFdaSilvaYY
Signed-off-by: Rich Salz <rsalz@akamai.com> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-02-26Implement new multi-threading APIAlessandro Ghedini
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>