> > > So IMO what Paul Sheer is doing - disabling all locking in OpenSSL given > > that there won't be any static and/or global variables in the OpenSSL > > code called is 100% safe thing if the threads do not share any data > > manipulated within the OpenSSL library. > > But that's not what he's doing. He's compiling OpenSSL single-threaded, > that > is, without specifying the compiler and configuration options required for > multi-threaded code. That this disables locking function calls is just one > thing it does. >
The other thing it does is fail to define errno as (*__errno()). Because OpenSSL is careful not to use many of the more threadishly two-faced standard library calls, these are actually the ONLY two things it disables. On all systems, the multithreaded compiler options do nothing but, 1. link certain library calls with Thread Local Storage versions, 2. #define certain other library calls, and 3. handle main() initialization and fork() and exit() differently. 4. Use a thread-safe malloc. OpenSSL never used any of the calls in point 1. or 2. and is miles away from 3. As for 4., this is dealt with in my previous email. (Well - I sure HOPE everything I'm saying here is true!! :-) Locking with no contention is not "pretty expensive", it's darn near free. Oh? If this is true it changes things somewhat. But I must say that I believe that no-one has ever used OpenSSL with 10'000 concurrent SSL objects. So I'm not going to take the chance that there will be any performance degradation. I'd rather have the GUARANTEE that there is no lock contention AT ALL. > This assumption is a common cause of premature optimization and buggy and > hard to maintain code. :-) You have my full agreement here! I do agree that it's at least possibly interesting to provide alternate code > paths that minimize locking for possible environments where there's some > value to minimizing locking. However, I bet you would have to work awfully > hard to create a real world case where the locking was expensive that > wasn't > easily fixed by the same application-level changes you would have to do > anyway to make this work. I intend to work that hard!! Kind regards -paul
