> Oh. I'm sorry. Someone needs to use a keyword 'volatile'. Sorry, doesn't help. > Bingo. Problem solved on the improper optimization issue.
What specification says that 'volatile' causes any particular semantics across threads? I must not have read that one. The 'volatile' keyword is only defined in the C and C++ standards, and neither of those address multi-threading. You might think that multi-threading standards would extend 'volatile' to have multi-thread semantics. The fact is, they don't. If you can cite one threading standard that specifies semantics for 'volatile', please do so. The reason they don't is quite logical. First, it penalizes code that uses 'volatile' for its documented purposes (such as 'longjmp' and signals). Second, they instead provide much more flexible primitives (such as mutexes) which solve a larger range of problems than a variable qualifier ever should. In short, *nobody* has any idea what effect 'volatile' might have on muli-threaded code on future compilers and future CPUs because *no* standard says what it should do. For example, Itanium compilers do not put memory barriers before or after accesses to 'volatile' variables precisely because it heavily penalizes sensible code and better ways to access shared variables are provided. > Can we commit the patch so that we don't have to keep getting hit by 2 > or 3 threads about valgrind complaining about reachable pointers at > the end of program execution every month? This /is/ an OpenSSL > library bug, and it /does/ need to be addressed -- regardless of "it's > only 36 bytes", relying on an operating system cleaning up after you > is sloppy programming at best and bug-laden at worst. Where these kinds of things can easily be fixed, they *definitely* should be. Anyone who doesn't want to "waste time" cleaning up doesn't have to call the cleanup functions at all. I do not in any way oppose making clean up functions do a better job of cleaning up where that is essentially free. > Remember, not all architectures have memory management units, either. Even architectures without memory management units keep track of what memory belongs to a process and free it when that process terminates. It's hard to imagine an architecture that couldn't do that where you wouldn't just keep your libraries spun up all the time. I can't think of any. In any event, on such a platform, you probably couldn't use much commodity software. The trade-offs in design would skew very differently. There are SSL libraries aimed at that market, and I don't think OpenSSL is really trying to do that. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
