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