The point is that due to the openSSL API, it is not possible in all
situations for a Continuation to be queued for later execution.
As for the type, we already have a transform specific continuation creation
call (TSTransformCreate), we could do something similar to TLS hook
continuations.
Yes, that makes sense, there could be a warning in the documentation
that the critical section must be minimal as it blocks an entire Event
Thread.
>From my reading of the code, TSReenableVConn() can queue the next
continuation of the hook, due to a mutex associated with the TLS
connection not the
I don’t see a way myself, that is why I was suggesting doing a blocking lock.
If the users passes a mutex then there should be a critical section in the
callback and they would be doing a blocking lock anyways.
-Bryan
> On Feb 12, 2019, at 9:28 AM, Walt Karas
> wrote:
>
> I don't see any
I don't see any way to change the API to require a TSCont that has no
mutex. Unless we create some new type like TSContNoMutex, but there
would be a ton of cascading consequences that don't seem worth it.
On Tue, Feb 12, 2019 at 11:25 AM Bryan Call wrote:
>
> I am against creating an API that ac
I am against creating an API that accepts a mutex and then later asserts
because a mutex was passed.
This goes against the work that has been done on creating continuations with a
mutex and ATS is supposed to handle the locking for you.
-Bryan
> On Feb 11, 2019, at 8:19 AM, Alan Carroll
>
> 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 w
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
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 Couldn’t you change the lock to be a blocking
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 wrote:
>
> @macisasandwich ran into this when working with port ready changes
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 tr
@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 a
11 matches
Mail list logo
