The NTLM Windows SSPI code uses static globals to keep track of a DLL and interface (see http_ntlm.c).
The attached patch moves the globals into the connectdata structure. The lifetime of the loaded
DLL and interface will be the the same as the previous implementation (the connection), but the race condition is removed.
Patch for thread safe SSPI
Logged In: YES
user_id=1110
Originator: NO
This seems to load the DLLs a little bit more often than necessary. Won't it make more sense to add the new struct members to (somewhere in) the SessionHandle struct?
Different take - initialize at curl_global_init time
Logged In: YES
user_id=669005
Originator: YES
What do you think of loading the DLL once at curl_global_init() time and unloading it
at curl_global_cleanup()?
Patch attached.
File Added: curl-ntlm-thread-safe-sspi-v2.diff
Logged In: YES
user_id=1590006
Originator: NO
Since Constantine is certainly working on this SSPI area.
Wouldn't it be interesting to get rid of the loadlibrary (dlopen) stuff and link with that library in the same way ws2_32 and others are used ? Its only 20 Kb more or less.
Would this be technically possible Constantine, or is dynamic linking mandatory for some obscure reason ?
Makefiles could be adjusted to link with 'secur32' when SSPI is required. And if someone still requires it to work on Windows NT then 'security' should be used instead of 'secur32'.
Just thinking outloud
Logged In: YES
user_id=669005
Originator: YES
The original motivation for going the LoadLibrary route was Windows NT 4.0/9x compatibility. NT 4.0/9x is not important for my application.
http://curl.haxx.se/mail/lib-2005-11/0059.html
Windows 9x doesn't have security.dll
Windows NT 4.0 doesn't have secur32.dllf
-Costa
Logged In: YES
user_id=1110
Originator: NO
Thanks! The v2 patch was applied and committed (with minor edits).