"getting the TSEventThread from a vconn, txn, ssn instead of implicitly trusting that the current thread is relevant?"
I'm not sure what this means. Those objects don't have threads explicitly associated, it's more implicit. If the code is in a callback on a hook for the object, then the current thread is relevant, effectively by definition. But as soon as I read this I realized you were going to bring up the continuation thread affinity issue. "moving a client vconn to a certain thread" - that would be challenging. I'd rather move the plugins to the NetVC thread. This is one aspect of getting the mutex locking thread - that's the thread to which to move. "check the callback continuations in the current API?" - check them for what? I don't understand this question. "getting the TSEventThread of a TSThread" - that's fine, with the understanding that not every TSThread is a TSEventThread so this may yield a null result. Unwinding the call stack to deal with conflicting locks is something that's done in the core quite a bit, so yes it would be nice if plugins could do that as well. It's effectively a "yield" with regard to the ATS event dispatching logic. I will try to remember what we talked about with thread aligned scheduling, there have been multiple schemes I've discussed with Jason.
