I don't see any way to change the API to require a TSCont that has no mutex. Unless we create some new type like TSContNoMutex, but there would be a ton of cascading consequences that don't seem worth it.
On Tue, Feb 12, 2019 at 11:25 AM Bryan Call <bc...@apache.org> wrote: > > I am against creating an API that accepts a mutex and then later asserts > because a mutex was passed. > > This goes against the work that has been done on creating continuations with > a mutex and ATS is supposed to handle the locking for you. > > -Bryan > > > > > On Feb 11, 2019, at 8:19 AM, Alan Carroll > > <solidwallofc...@verizonmedia.com.INVALID> wrote: > > > > Putting a blocking lock on those calls will eliminate the advantages we got > > from moving to 1.1.1 from 1.0.2 in terms of lock contention. It will mean > > people will write plugins with locks, put them on a TLS hook, and then > > complain "ATS sucks, it's so slow doing TLS". > > > > Also, it's already very easy to write code that asserts later on. Trying > > scheduling a TSCont that doesn't have a mutex. > > > > On Fri, Feb 8, 2019 at 7:38 PM Susan Hinrichs > > <shinr...@verizonmedia.com.invalid> wrote: > > > >> Yes, we could blocking lock easily enough too at the potential cost of > >> blocking the thread. > >> > >> We could block and issue a warning on the hook call to give people some > >> hint that this might be a performance problem. > >> > >> On Fri, Feb 8, 2019, 7:21 PM Bryan Call <bc...@apache.org wrote: > >> > >>> Couldn’t you change the lock to be a blocking lock for the SSL APIs? > >>> > >>> It seems like a bad interface to be able to write and compile code that > >>> will assert later on. > >>> > >>> -Bryan > >>> > >>>> On Feb 7, 2019, at 2:51 PM, Susan Hinrichs <shinr...@apache.org> > >> wrote: > >>>> > >>>> @macisasandwich ran into this when working with port ready changes in > >>>> autest. The extra port probe tied up the test ssl plugin (for > >>> tls_hooks15) > >>>> which exercised a TLS hook on a continuation with a mutex. Since the > >>> invoke > >>>> method could not grab the lock, the assertion went off. > >>>> > >>>> I went back to look at how the TLS code should grab the continuation > >> lock > >>>> before calling invoke. But there are many (most) cases where the TLS > >> hook > >>>> cannot be delayed by a reschedule in the case when the lock cannot be > >>>> obtained. > >>>> > >>>> In most cases for such global continuations, you would not want a lock > >> on > >>>> the continuation for performance reasons. In the case where locking is > >>>> needed, it would be better done by the plugin writer internal to the > >>> plugin. > >>>> > >>>> I made a PR with code changes to force continuations to not have > >> mutexes > >>> if > >>>> they are using the SSL hooks. With this code change, Trafficserver > >> will > >>>> assert if a continuation with a mutex tries to attach to a SSL hooks. > >>>> > >>>> The PR with code change > >>> https://github.com/apache/trafficserver/pull/4939 > >>>> > >>>> Please share your comments/concerns. > >>>> > >>>> Thanks, > >>>> Susan > >>> > >>> > >> >
