Reordering new API's that have a libctx, propq

[Richard Levitte]

On Wed, 09 Sep 2020 16:08:10 +0200,
Tomas Mraz wrote:
> 
> On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote:
> > > On 9 Sep 2020, at 9:38 pm, Tomas Mraz <tmraz at redhat.com> wrote:
> > > 
> > > We could even provide a convenience thread local stack of lib
> > > contexts
> > > so the caller would not have to keep the old value but would just
> > > push
> > > the new libctx when entering and pop the old one when leaving. With
> > > that, I think the changes needed in the application code would be
> > > fairly simple and minimal.
> > 
> > Let’s not overcomplicate things.
> > We went through this discussion back when this was introduced.
> > 
> > 
> > Push is:
> >     OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);
> > 
> > Pop is:
> >     OPENSSL_CTX_set0_default(prevctx)
> > 
> > 
> > I don’t see having an explicit stack of these is of any benefit to
> > anything but unwarranted complexity.
> 
> There is one thing where it would be IMO helpful - let's say libcurl
> has a callback into a calling application. With the current API in
> libcurl API calls you would put the
> calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx
> ) at the beginning and end. But you would have to save the prevctx
> somewhere in the libcurl context structure because on callbacks you
> would have to temoprarily reset the context to the prevctx value. If we
> implemented real stack it would not be needed. But yeah, I am not sure
> this convenience is that much worth it.

A stack becomes potentially extra churn in memory allocation for every
push, and wondering what to do with the stack if the stack
functionality fails.  So yeah, I'm thinking that it's not really worth
it.

Cheers,
Richard

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