On Wed, Mar 14, 2018 at 01:26:38AM +0000, Salz, Rich wrote: > So a major reason, as you explained, for having per-thread DRBG's is to > reduce contention. When threadA creates an SSL object, the parent DRBG will > be the threadA one. Therefore you have to introducing locking, since threadA > might create two SSL objects and they could end up being used in threadB and > threadC and each need to reseed from their parent. In order to do that > safely, threadA also has to do the locking to avoid conflict. That defeats > the major gain of per-thread. > > I think having the SSL object parent be whatever the *current* thread DRBG is > seems like the best, if not only, way to go.
Either that or just always use the per-thread DRBG for the current thread, and don't bother to do per-SSL at all. -Ben _______________________________________________ openssl-project mailing list firstname.lastname@example.org https://mta.openssl.org/mailman/listinfo/openssl-project