> Yes, that's what BoringSSL does. They have three implementations: pthread, > windows and none (which is just nops). I don't know what the availability of > pthreads is on the above platforms (NW, OS/2 and VMS), but it should cover > quite a bit of platforms.
I'd instead have two: native or none. Where hopefully native is mostly pthreads, but for NW,OS/2,VMS it can at least start at as none. > Basically they deprecated the current CRYPTO_lock and CRYPTO_THREADID > API, and replaced that with mutex objects (CRYPTO_MUTEX). Not sure about that, I could be persuaded either way, for CRYPTO_lock. The THREADID might need to stay for platform portability. > Additionally, > this API provides thread-local storage support and "once" objects (to > execute functions only once, for example for initialization). I'd probably leave thread-local storage up to the application. But the once stuff would be useful *iff and only iff we used it to make initialization simpler.* > On top of the CRYPTO_MUTEX they added a reference counting API (which > can use > C11 atomics instead of mutexes), but this is not used a lot so it can be > ignored > for now. We already have CRYPTO_add ... _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev