Thoughts about library contexts

[Richard Levitte]

On Mon, 18 Feb 2019 11:17:45 +0100,
Matt Caswell wrote:
> At the moment OPENSSL_CTX is implemented using CRYPTO_EX_DATA. An alternative
> implementation approach would be that the struct is internally transparent and
> is just a bucket of stuff (without using CRYPTO_EX at all). I guess the reason
> for doing so would be performance (to reduce the indirection of going via
> CRYPTO_EX).

The central idea here is that OPENSSL_CTX is a bag of "stuff" and that
each sub-system should decide on their own what its "stuff" is.

Of course, the bag could have been made like a structure with
specific pointers for each sub-system that wants to store something,
but I find that approach a bit messy, as the sub-systems become less
self contained, and also have less control over their own "stuff".

For example, if there's a need for a lock to retrieve some data, does
everyone else have to learn to use that lock, and what happens if
someone forgets, i.e. how error prone can it become?  As an
alternative, if the sub-system defines its own internal API for access
of stuff, that does all the needed locking, why does everyone else
need to know exactly how it's stored in the library context?

The reason why I chose CRYPTO_EX_DATA for internal storage?  I was
actually about to implement a generic "bag", when I realised that we
already have that in CRYPTO_EX_DATA.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/