Hi Peter, On Sep 11, 2008, at 2:48 PM, Peter Waltenberg wrote:
> 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).
I agree. These are systems I personally have no exposure to on a
daily basis, but I wouldn't like to see them break.
>
> 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.
Yes, that would be bad. Especially since this expedition is intended
to relieve my own customers from having to keep multiple OpenSSLs
around.
> 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.
Yes, putting all the implementation/platform specific stuff in
callbacks is very elegant. What would be better:
1) Any application developer has to write and set the upcalls
2) A default implementation on some platforms where it's known to
work, meaning
that it *may* be there or *may* not be there and the appliation
developer is
expected to have the wherewithal to find out. Any time that app
is ported
to a new platform the rules may change w.r.t. OpenSSL and locking
Much as I like to reduce repetitive application code, option 2 seems
like kind of a nightmare situation.
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
