> On 9 Sep 2020, at 9:38 pm, Tomas Mraz <tm...@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. Pauli
- Re: Reordering new API's that hav... Tim Hudson
- Re: Reordering new API's that... Nicola Tuveri
- Re: Reordering new API's that hav... Richard Levitte
- Re: Reordering new API's that... Tim Hudson
- Re: Reordering new API's that... Richard Levitte
- Re: Reordering new API's that... SHANE LONTIS
- Re: Reordering new API's that... Richard Levitte
- Re: Reordering new API's that... Michael Richardson
- Re: Reordering new API's that have a libctx, propq Richard Levitte
- Re: Reordering new API's that have a libctx, propq Tomas Mraz
- Re: Reordering new API's that have a libctx, p... Dr Paul Dale
- Re: Reordering new API's that have a libct... Tomas Mraz
- Re: Reordering new API's that have a l... Richard Levitte
- Re: Reordering new API's that have a l... Dr Paul Dale
- Re: Reordering new API's that have a libctx, p... Richard Levitte
- Re: Reordering new API's that have a libctx, propq Matt Caswell
- Re: Reordering new API's that have a libctx, propq Tim Hudson
- Re: Reordering new API's that have a libctx, p... Matt Caswell
- Re: Reordering new API's that have a libct... Tim Hudson
- Re: Reordering new API's that have a l... Matt Caswell
- Re: Reordering new API's that hav... Tim Hudson