> So the point you are trying to make is, while the function would > solve the > purpose of freeing the compression methods, However the lock are > not really > required in the usage secnario of this function?
If the usage scenario is solely final shutdown of the library, then the lock is not required. If the usage scenario is larger than that, then the double-checked locking should be removed and all tests should be done under the lock. The current code is an insensible compromise. The double-checked locking makes no sense in either usage scenario. If it's purely a shutdown function, then the "optimization" is a pure complication -- there's no need to acquire the lock in any case. If it's not purely a shutdown function, then the "optimization" is prohibited by the pthreads standard and its behavior is undefined and it could break on future CPUs, compilers, or platforms. I admit it's unlikely to break on future x86 platforms -- too much existing x86-only code would break. But I have seen similar types of 'optimizations' break on new CPUs when those CPUs used optimizations that were not imaginable at the time the code was written. OpenSSL has a way for platforms to provide safe multi-threading primitives. If additional primitives are needed or beneficial for optimization, they should be provided the same way. OpenSSL itself should not make assumptions that are specifically prohibited by the standards it is designed to work with. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
