On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: > > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? > > It seems to have trouble to keep up with new architectures.
New architectures are not really a problem because between a) decent compilers with C11 and/or non-C11 atomic intrinsics, b) asm-coded atomics, and c) mutex-based dumb atomics, we can get full coverage. Anyone who's still not satisfied can then contribute missing asm-coded atomics to OpenPA. I suspect that OpenSSL using OpenPA is likely to lead to contributions to OpenPA that will make it better anyways. What's the alternative anyways? We're talking about API and performance enhancements to OpenSSL to go faster on platforms for which there are atomics, and maybe slower otherwise -- or maybe not; maybe we can implement context up-/down-ref functions that use fine-grained (or even global) locking as a fallback that yields performance comparable to today's. If OpenPA's (or some other such library's) license works for OpenSSL, someone might start using it. That someone might be me. So that seems like a good question to ask: is OpenPA's license compatible with OpenSSL's? For inclusion into OpenSSL's tree, or for use by OpenSSL? Nico -- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev