Reordering new API's that have a libctx, propq

[Tomas Mraz]

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.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]