This is the current state of the APIs. I have this tracked on my private branch on github, please provide feedback for it. Thanks! https://github.com/duke8253/trafficserver/pull/5
On Tue, Aug 21, 2018 at 3:36 PM zzz <z...@apache.org> wrote: > 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 > > > -- *Fei Deng* E: f...@oath.com 1908 S First Street Champaign, IL, 61820
