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

Reply via email to