As a quick response, it sounds like most of your issues would be addressed by thread affinity for continuations. I'll see if I can get some write up done for the summit. There are other issues beyond yours that I think would also benefit from that.
On Thu, Aug 16, 2018 at 12:56 PM Kees Spoelstra <kspoels...@we-amp.com> wrote: > 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) > -- *Beware the fisherman who's casting out his line in to a dried up riverbed.* *Oh don't try to tell him 'cause he won't believe. Throw some bread to the ducks instead.* *It's easier that way. *- Genesis : Duke : VI 25-28
