> Yeah, I guess both pthread and Windows implementations can both be called > "native".
Yes, that's the intent. > FWIW I did a quick research and NW, OS/2 and VMS all seem to support > pthreads (but I don't know anything about those platforms, so I may be > wrong). That would be good. > Incidentally a big user of the lock and thread-id API is mem_dbg.c, and > looking at the code in it I was wondering whether we really need it, Take a look at: https://github.com/openssl/openssl/pull/450 > FWIW the ASYNC pull request [0] already uses thread-local storage, but > instead of using the pthread API (which is probably more portable) it uses > the __thread syntax. That should probably be changed. > The ERR_STATE thing could also be simplified a lot by using thread-local > storage (and the fallback thread-local support can be implemented using > THREADID as it's currently done in ERR_STATE itself, but all the complexity > would be moved to its own file, leaving err.c cleaner). Yes, that should be changed too. In case it's not clear, I've changed my thoughts. Thread-local storage is more important and useful (thanks Kaduk and Ghedini!) than pthread-once kinds of things. I'd like to see a single API that initializes *everything* (or maybe takes a flag-bits) and a peer routine that takes down everything. It would handle fork() and reset the RNG, and so on. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
