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 >>> >>> >>
