On Mon, 15 Feb 2010 15:19:23 +0100 "Steffen DETTMER" <steffen.dett...@ingenico.com> wrote:
> * Sad Clouds wrote on Mon, Feb 15, 2010 at 13:18 +0000: > > 2. Rationale for callbacks? > > > > Pushing some of the responsibility for locking OpenSSL internal > > structures to application developers seems a bit lame. Why not get > > rid of locking callbacks and have OpenSSL handle it transparently > > inside the library? This promotes the idea of abstract data types > > and encapsulation and avoids the whole mess of static/dynamic > > callbacks. > > (I'm just guessing - please correct me where I'm wrong). > > Delegating functionality via callbacks allows arbitrary > implementations; I would not consider this lame > - but clean, strong, orthogonal, KISS and divide-and-conquer :) > > Neither ANSI-C nor ISO-C tell anything about multi-threading or > mutex locking, so handling that transparently inside the library > would introduce additional dependencies (e.g. to POSIX threads) > and thus would not be portable. I think pretty much every Unix platform standardised on Posix threads by now. Using locking implies that you're using threads, and that is Pthreads API on Unix. Non Unix platforms should be dealt with on individual basis, using whatever native threading/locking primitives they provide. I still think it's library's responsibility to pick the most efficient locking primitives for a given platform and use them transparently, without exposing the semantics to the application code. What happens if your application is linked to other libraries which use OpenSSL and try to set their own locking callbacks? I have a feeling the locking callbacks mechanism is the leftover from the 90s era. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
