On Thu, Aug 16, 2018, 20:39 Alan Carroll <solidwallofc...@oath.com.invalid> wrote:
> "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. > When coordinating between txns and reenabling or accessing object a from object b's hook you might not be so lucky.A hook for A might be called on an unexpected thread and fun stuff will happen. Often you will be lucky because core has a lot of explicit alignment checks and reenabling A will be done on it its original thread. 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. > I meant outgoing netvc connections, my bad, but we have the technology to make it better, :), in the global http server connectionpool we do this with the netvcs to align with the txn/sm threads. I don't know what has an higher impact thread jumping or moving the netvc. Moving netvcs to other threads might have some impact on data in flight, I think Susan knows about the limitations of this. Wouldn't it be nice if we had connection pool constructs which we could reuse :) instead of reinventing. Somehow when pulling threads the whole world starts to unravel. > "check the callback continuations in the current API?" - check them for > what? I don't understand this question. > The callback cont for some async tsapi calls might not be called on the same thread. It would be nice to know the guaranteed behavior of calls with callback continuations without checking core code (for example DNS)
