Peter Waltenberg wrote:
"
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.
This used to be a problem on Solaris too (at least SunOS 5.6 thru 5.8) but I
don't know if it still is. We ran into it all the time when configuring
LDAP-enabled authentication; the CDE login would crash if you didn't build
pam_ldap, nss_ldap, and libldap *just right*... The CDE libraries came along
with a malloc wrapper, and mixing threaded+nonthreaded code would bring in two
different malloc implementations. Instant 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?)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
