" ... For vendors it could mean that OpenSSL is shipped with a default set of locking callbacks (e.g. Solaris could use phreads/solaris threads) but that is obviously not a generic solution and will not be suitable for all platforms/distributions. I seem to remember having this conversation a few months ago... :) "
I disagree, at least for the OS vendors defaulting to using the standard threading model *is* the sane thing to do. I'd go further and say that using the default OS thread model is the only reasonable choice for an OS supplied library. "All" OpenSSL needs to do is provide that as a config time option and most of these problems go away. Anyone with a really unusual configuration can build and ship their own OpenSSL libraries without the default thread support built in and provide their own callbacks - as they presumably do now. Peter Peter Waltenberg Architect IBM Crypto for C Team Tivoli Software Australia Development Laboratory Gold Coast Phone: +61 7 5552 4016 Fax: +61 7 5571 0420 ICC Home page: https://cs.opensource.ibm.com/projects/icc From: Mark Phalan <mark.pha...@sun.com> To: openssl-dev@openssl.org Date: 29/06/2010 02:00 AM Subject: RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw Sent by: owner-openssl-...@openssl.org On Mon, 2010-06-28 at 07:06 -0700, David Schwartz wrote: > > Guess I replied too quickly... I see why you thought I was spreading > > misinformation. Of course I agree that every library could be modified > > to use atomic instructions available on their CPU to synchronize. Its > > just a lot of modifications to be made considering the vast amount of > > code out there that uses OpenSSL. I'd like to see OpenSSL take care of > > this (which is what I though you were arguing for too). > > > > -M > > Actually, that wouldn't work. What if you're using a threading library that > permits threads to run in different SMP domains? In that case, the atomic > instructions would only synchronize between threads running in the same SMP > domain. > > If one thread in one SMP domain attempts to set the thread synchronization > primitives at the same time as a thread in another SMP domain does so, the > CPU synchronization instructions would be insufficient. Such a platform > might require a specific "synchronize memory view across domain" > instructions when a lock was acquired or released, for example. > > I think you're missing the point that OpenSSL doesn't just support the > typical platform-provided threading libraries. It supports *any* threading > library the compiler can support. There is no guarantee that CPU-atomic > operations are atomic in the same scope as any possible threading library > the compiler can support requires. > > Trying to supply the library with atomic operations known safe for the > required atomicity of the threading library in use creates a chicken and egg > problem. You would need atomic operations to specify the atomic operations. Point taken. I suppose what I'm really after is a way out for libraries to be able to "do the right thing" with a minimum of code change. From what I've seen in the wider opensource world is that either libraries don't set the callbacks at all or set them without even checking to see if they're already set. The way OpenSSL currently works I don't see a simple solution. For vendors it could mean that OpenSSL is shipped with a default set of locking callbacks (e.g. Solaris could use phreads/solaris threads) but that is obviously not a generic solution and will not be suitable for all platforms/distributions. I seem to remember having this conversation a few months ago... :) -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
