On Fri, Oct 23, 2015 at 05:13:02pm +0000, Salz, Rich wrote: > > 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.
Yeah, I guess both pthread and Windows implementations can both be called "native". 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). > > 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. I think it could be possible to implement CRYPTO_MUTEX and thread-local storage support by using CRYPTO_lock and CRYPTO_THREADID, so that could be kept as fallback (e.g. it could be hidden behind OPENSSL_NO_DEPRECATE). 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, considering that now we have better tools to debug memory problems. So at some point I'd like to try and make OPENSSL_malloc & co. aliases for malloc(), realloc() and free() and remove (or deprecate) the custom memory functions... but that's probably a whole different discussion. > > 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. 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. 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). > But the once stuff would be useful *iff and only iff we used it to make > initialization simpler.* The RAND code would be an obvious candidate, but even in BoringSSL once objects are not used a lot (not that it would add a lot of code since it would be just a wrapper for pthread_once()). Cheers [0] https://github.com/openssl/openssl/pull/433
signature.asc
Description: PGP signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
