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
