I think we should handle this such that an application can provide
either global "type" locks (as at present) or structure based locks.
Then the application can decide whichever is more appropriate to the
environment in question.

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

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

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to