As has been mentioned before, I've given some thought to having
thread-locks with a higher granularity than we have today.  As it is
now, the locking is done at type level (class level for the OO
fanatics).  This means that if some thread locks CRYPTO_LOCK_RSA, all
operations that need to lock that lock will hang until the first one
is done.  This degrades the potential performance quite a lot, I'd
think.

After having given some OpenSSL-specific locking mechanism a bit of
thought, I've concluded that it's not possible to make something that
is portable and as efficient as whatever is used in the operating
system.  This means that we would basically use the dynamic locks that
I implemented some time ago or something close to it.

Using dynamic locks would create fragmentation of the heap, but there
are solutions to that, to some level of intricacy.  However, there's
something else that disturbs me a bit, and it's the thought that locks
may be a limited resource and can't therefore be littered all over the
heap without some performance hit or something else.

What I'd like to know is if the following structures are basically
just a memory blob with some bits that are fiddled with, or if it's a
handle to some bulkier resource.  It's probably OK to create, say,
10000 of the former without ay problem, the latter would create
problems in those quantities:

         pthread mutexes

         Windows critical sections

         others?

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to