I'm looking into this right now. Already have the TSContScheduleOn and TSContScheduleOnEvery APIs done. Still working on getting the thread affinity.
On Thu, Aug 16, 2018 at 12:59 PM Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > 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 > -- *Fei Deng* E: f...@oath.com 1908 S First Street Champaign, IL, 61820
