> Also, it's already very easy to write code that asserts later on. Trying scheduling a TSCont that doesn't have a mutex.
A little off-topic: There are already several useful TS API functions that require a mutex. Currently the plugin author must be diligent in reading the documentation to learn when a continuation should be created with a mutex, and an omission leads to weird problems that can be difficult to debug. Have we considered requiring a mutex for such API functions, apart from requiring them for hooks (TLS or otherwise)? On Mon, Feb 11, 2019 at 10:29 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 > > > > > > > > >
