| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We explicitly avoided TryAcquireSRWLockExclusive() because of crashes. This
issue was caused by a MinGW-w64 bug (mingw-w64 fix 46f77afc). Using a newer
toolchain works fine.
While try_write_lock() obviously can fail, not supporting it is not really an
option, as some algorithms depend on occasionally successful calls. Certificate
caching in the certificate manager and the cred_set cache rely on successful
try_write_lock()ing.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of cleaning up all thread-values during destruction, cleanup handler
is invoked when a thread detaches. Thread detaching is cough using the Windows
DllMain() entry point, and allows us to basically revert 204098a7.
Using this mechanism, we make sure that the cleanup handler is invoked by the
the correct thread. Further, this mechanism works for externally-spawned
threads which run outside of our thread_cb() routine, and works more efficiently
with short-running threads.
|
|
|
|
|
| |
For x86_64 it does not actually matter, but for i686 builds the call convention
is different with WINAPI.
|
| |
|
| |
|
|
|
|
|
| |
This avoids any races during cleanup invocation if multiple cancel() requests
come in.
|
|
|