You need to be really careful here. Simply being dependent on pthreads and
linking to non-threaded code is pure poison on some OS's. (HP/UX variants
come to mind).
If you do decide to add a default set of thread callbacks, you'll at least
need a build configuration to disable it - I'm only guessing, but there are
probably quite a few users with either custom threading systems, or still
running unthreaded. That leaves you with the unpleasant possibility of
needing two versions of OpenSSL on a system, one linked to pthreads, one
not.
I suspect that the current situation,i.e. OpenSSL built thread safe, but
without explicit dependencies on the system pthread library is the best of
all possible options. Simply avoiding the problem with the one engine
that's causing problems does seem like the least disruptive option.
Peter
From: Sander Temme <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [email protected]
Date: 12/09/2008 01:46
Subject: Re: [openssl.org #1736] Enhancement Request: do away with error
in chil engine in absence of dynamic locks
On Sep 11, 2008, at 7:04 AM, [EMAIL PROTECTED] via RT wrote:
> On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote:
>> 2) Have the engine provide its own callbacks that get set in case the
>> application does not provide (presumably more suitable) alternatives:
>
> I think it would be entirely sensible for OpenSSL to offer a build-
> time
> configuration option to implement default locking/id callbacks using
> pthread functions like this. It would be necessary also to link
> libcrypto against -lpthread and/or use the -pthread compiler flag, to
> avoid only picking up dummy libc stubs on some platforms.
>
> That seems far better than requiring every single OpenSSL
> application to
> implement exactly the same code over and over again- and in fact for
> many to do so incompletely, omitting the dynamic lock support.
I agree, a fallback implementation would give OpenSSL a more robust
interface, and prevent some code smell for implementors. Right now it
seems that the chil plugin is the only place where dynamic locks are
actually used, but I assume that will change in the future.
It seems to me that a generally available set of fallback dynamic
locking callbacks would be of interest to the library at large, not
just to the chil plugin so I'd suggest putting those routines
somewhere else, perhaps closer to crypto/cryptlib.c where the global
function pointers are allocated?
My direct (and driven by my affiliation) interest is to unbreak the
breakage of the chil engine in the absence of dynamic locks, and to
see that backported to 0.9.8. However, putting the fallback
implementation in may be the kind of deeper surgery you don't want to
backport... Can we start a two-pronged approach where we apply and
backport my original openssl_chil_nolocks_donotbreak.patch and then
look into the fallback routines? The former is entirely localized to
the chil engine and does not stand in the way of the latter (since
when that's done the engine will just find the callbacks in place).
Thanks,
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
