Unfortunately, I don't see what else we can do. My view is in alignment with Susan's, that as long as a number of the TLS callbacks can't be rescheduled and therefore can't be reliably locked, it's best to have a simple and clear rule that none of them are. Otherwise we are asking for a lot more trouble and plugin writer pain down the road than this will cause.
On Thu, Feb 7, 2019 at 4: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 >
