From: Dr S N Henson <[EMAIL PROTECTED]>

drh> I can see a couple of ways to handle this. One is to let the callbacks
drh> handle everything: add an extra argument that passes the address of the
drh> structure associated with the lock and let them use it as an opaque ID
drh> and handle a lock pool as it sees fit.

That will be a problem.  Consider realloc().

drh> Alternatively we could add a field to the relevant structures a bit like
drh> the current "references" which is an opaque pointer or contains an
drh> opaque pointer which the lock callback can use for whatever purpose it
drh> wants.

That's basically already possible today, with little extra code,
through the dynlock functions.

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