I feel like saying few words. One should recognize that by the time
multi-threading support was taking shape there was a whole variety of
threading implementations and callbacks were the only way to convey the
specifics. Nowadays we're pretty much talking only about pthreads and
Windows, and one can indeed argue why wouldn't OpenSSL simply default to
either of the two when appropriate. While it's more than appropriate on
Windows as it is, on pthreads-powered Unices it's not as obvious.
Because pthreads can be undesired in some situations. Basically it boils
down to question whether or not libcrypto may be linked with libpthread
or not. And answer is actually "not desired." Ideally libcrypto should
*detect* if *hosting* application is linked with libpthread and only
*then* adjust accordingly. Is there way to detect if application is
linked with libpthread at run-time? There is DSO_global_lookup.
As for pthread_once [and Windows counterpart]. I'd argue that it would
be more appropriate to initialize the default callbacks through
initialization segment (facility used for "pre-main" execution of
"constructors"), which is guaranteed to be MT-safe. Such framework (as
well as "destructors") would be useful in more places.
As for config-time detection. My major objection is following. Software
is called so for a reason, and config-time detection is effectively
against its nature. Because it "hardwires" it to specific set of
interfaces. Wouldn't it be more natural for *soft*ware to detect feature
at *run-time* and adapt? This is actually what's is implemented in
several places in OpenSSL.
I'm making progress slowly (not my main project). I've run into a bit
of a problem: the dynlock callback setting cannot be made thread-safe
due to the setter API's using three functions to set three related
callbacks.
Also, I'm not sure that the dynlocks need a default implementation. It
seems they don't, at least not as far as *apps* are concerned. Please
let me know, though I'm inclined to provide a default implementation
anyways, just because it's no big deal.
A few notes and questions:
- Locks in OpenSSL are really reader-writer locks, but the sample code
in crypto/threads/*.c uses mutexes only.
How important is it that reader/writer locks be used instead of
exclusive locks?
For historical reasons mentioned above mutexes are common denominator.
Whether or not one should switch to more sophisticated primitives is
question about whether or not do we want to support legacy
multi-threading systems. The answer is probably yes. Of course one can
add more callbacks, see which one are set and opt for more refined
methods if available. But
- The add_lock stuff should just use OPENSSL_atomic_add() wherever it
exists.
How would I determine at build-time (in ./Configure and in
./crypto/lock.c) whether OPENSSL_atomic_add is available?
#ifdef OPENSSL_CPUID_OBJ
Well, DSO_global_lookup is more consistent with above:-) While we are at
it, it's appropriate to add atomic pointer swap that can be used to
maintain linked lists without mutex-ing.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
