From: Sean Walton <[EMAIL PROTECTED]>

swalton> You could a centralized locking system instead of heap.
swalton> Imagine creating a custom mutex table that is fixed (or even
swalton> dynamic).  As each mutex is allocated and freed, it would
swalton> come from this space.  Since it is centralized, it does not
swalton> fragment the heap, and sections of it could be swapped out of
swalton> RAM without intervention from the library (please note that
swalton> this is demand paging -- something Win2K has only begun to
swalton> play with).  Of course this would mean writing a new set of
swalton> mutex functions...

That's a way too.  The way I was thinking of was to make the mutex a
part of each structure that is allocated, but still be outside the
structure itself.  I'd do a malloc(size_of_mutex() + sizeof(RSA)) and
return a pointer to the RSA part of that blob.  I haven't thought
through everything yet.

This method would be intricate, that's true (and I said it would be
:-)), but it doesn't carry more administrative hassle than the object
itself, and we would avoid that extra pointer, or a pointer that
points to a table of pointers...

-- 
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