> > Really? So 'errno' refers to a process global in both cases?! > > (Note that I > > said the "definition", not the implementation.)
> Maybe we didn't understand each other - I don't say, that glibc without > multithread support and with it is the same. I say that linking single > threaded library which is simply reentrant but doesn't use any locking > itself to a multithreaded app is 100% safe thing to do. I think you are confusing two different definitions of "single threaded". You may mean by "single threaded" that no threading functions are ever called. This is a source code issue. The source either calls threading functions or it doesn't. But what the OP and I mean by single threaded is *compiled* single threaded. That is, without specifying whatever options the compiler wants to make code multi threaded. > Of course the > glibc itself is a different piece of code - the code of things like > malloc and errno will be definitely different when glibc is compiled > without any support for threads and locking. And I am all the time > talking about dynamic linking to glibc and not static. The problem is that when you dynamically link to glibc, you cannot control what version of glibc you get. If a newer version of glibc is available, you will get the newer version. You can reasonably rely on a newer version maintaining the same guarantees as the version you tested with. If it didn't, it wouldn't be declared compatible. However, you cannot reasonably rely on assumptions you made still being true. There is no inherent reason code not compiled multi-threaded and code compiled multi-threaded have to be compatible in *any* way. There is no reason code compiled re-entrant and code compiled multi-threaded have to be compatible in any way either. To the extent they do, it's simply a happy accident. > 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. > As locking can be pretty expensive in terms of CPU cycles Locking with no contention is not "pretty expensive", it's darn near free. This assumption is a common cause of premature optimization and buggy and hard to maintain code. > it is > desirable to allow using OpenSSL this way so to remove all static and/or > global variables in its code or at least isolate them and allow using > OpenSSL code without them being touched. Perhaps, but that would still require that you compile the library using whatever multi-threaded options your platform, compiler, and its configuration require. It would then by multi-threaded but wouldn't have internal locks. 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. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
