> 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

Reply via email to