"
I don't think you can avoid a dependency on the system threading library
though, but I don't see why that would be an issue. Many single-threaded
programs wind up requiring the threading library on many platforms anyway
as
it may contain functions like 'clock_gettime' or 'sched_yield'. (Does
anyone
know of a platform where this is a problem?)
"
Alas, yes HP/UX.
Link code built threaded and code built unthreaded on that platform and
your application dies a horrible death.
Peter
From: "David Schwartz" <dav...@webmaster.com>
To: <openssl-dev@openssl.org>
Cc: <mark.pha...@sun.com>
Date: 31/03/2010 11:37 AM
Subject: RE: libcrypto safe for library use?
Sent by: owner-openssl-...@openssl.org
Darryl Miles wrote:
> How does each of the 3 threads arbitrate in a thread-safe manner the
> initialization of the OpenSSL related libraries. How does any one of
> them know it is the "first user" ?
For existing code, there is no fix. They will set incompatible callbacks
and
they will break. I don't see anything OpenSSL can do to fix this other to
implement default callbacks and to claim attempts to change the callbacks
succeeded while silently failing them.
> Once each of the 3 users has finished using their copy of OpenSSL they
> can request the dynamic linker unload it "dlclose()". So it is also
> necessary for OpenSSL to know when the last user has closed the library
> and it needs to perform memory freeing and cleanup because there are no
> users left. How does any one of them know it is the "last user" ?
This is a great example of a case where OpenSSL should be wrapped. Again, I
don't think you can fix existing code. It's already going to do the wrong
thing, for example, shutting down OpenSSL. (Unless you want to make OpenSSL
shutdown functions silently do nothing but claim success.)
> You can still have a "default theading model" and still support all
> "known threading models" via reconfiguration before first use. There
> is
> no conflict here please stop implying there is one.
That's what we have now. The "default threading model" is single-threaded.
Others are supported by reconfiguration before first use.
> Setting the callback(s) is unsafe. Since another thread might be using
> them. Do you not get that ? There is no locking around the setting of
> them so therefore they are thread-unsafe, the method to set locking is
> not re-entrant. I harp back to my request for "re-entrant thread-safe
> OpenSSL APIs" for setting up the threading callbacks.
I agree, but I don't think there's anything we can do to help existing
code.
Existing code already does the wrong thing. I suggested a "register OpenSSL
user" and "deregister OpenSSL user" function which permits the user to
specify the threading model it's using and trigger a reference count.
(Overlapping callers with different threading models would result in an
error.)
I don't think you can avoid a dependency on the system threading library
though, but I don't see why that would be an issue. Many single-threaded
programs wind up requiring the threading library on many platforms anyway
as
it may contain functions like 'clock_gettime' or 'sched_yield'. (Does
anyone
know of a platform where this is a problem?)
DS
______________________________________________________________________
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
