I wait, with bright eyed anticipation, for the documentation for this! On Tue, Aug 21, 2018 at 9:47 AM Fei Deng <f...@oath.com.invalid> wrote:
> 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 > -- *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
