I think that would be better, because it's consistent with the current API.
Sorry if I wasn't clear on that before. On Mon, Mar 19, 2018 at 4:07 PM, Walt Karas <wka...@oath.com.invalid> wrote: > So is the upshot that the mutex param to the constructor should > default to nullptr? > > On Mon, Mar 19, 2018 at 4:04 PM, Derek Dagit <der...@oath.com.invalid> > wrote: > > A continuation's Mutex is also used for certain API functions, like > > TSHostLookup: > > > > https://docs.trafficserver.apache.org/en/latest/ > developer-guide/api/functions/TSHostLookup.en.html > > > > But you do not always need them. > > > > On Mon, Mar 19, 2018 at 3:48 PM, Alan Carroll < > > solidwallofc...@oath.com.invalid> wrote: > > > >> Yes. I have seen reference count numbers in the high teens for some > >> mutexes. > >> > >> On Mon, Mar 19, 2018 at 3:32 PM, Walt Karas <wka...@oath.com.invalid> > >> wrote: > >> > >> > So it's possible that two different continuations may be sharing a > single > >> > mutex? > >> > > >> > > >> > On Mon, Mar 19, 2018 at 1:37 PM, Alan Carroll > >> > <solidwallofc...@oath.com.invalid> wrote: > >> > > Walt - I think Derek is commenting stylistically, that if no Mutex > is > >> the > >> > > default for the C API, then it should be the default for the C++ as > >> well. > >> > > > >> > > What about a user conversion to TSCont in addition to an explicit > >> method? > >> > > If you could, writing this up as a Sphinx API doc would be cool. > >> > > > >> > > On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll < > >> solidwallofc...@oath.com> > >> > > wrote: > >> > > > >> > >> Indirectly. What's stored in the Continuation is a shared pointer > to > >> the > >> > >> Mutex. That shared pointer is destructed by TSContDestroy which > may in > >> > turn > >> > >> destruct the Mutex (or not, if there are still references to it). > >> > >> > >> > >> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas > <wka...@oath.com.invalid > >> > > >> > >> wrote: > >> > >> > >> > >>> I'm pretty sure TSContDestroy() also destroys any mutex for the > >> > >>> continuation. (Per our other discussion, I got exasperated > trying to > >> > >>> make sure of this looking through the code with just vi.) > >> > >>> > >> > >>> > >> > > >> > > > > > > > > -- > > Derek > -- Derek
