Thanks, Fei Deng, glad to hear the good news! Looking forward to the new PR.
2018-08-21 7:50 GMT-07:00 Alan Carroll <solidwallofc...@oath.com.invalid>: > 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 >
