Thanks, Kees, Otto, and Alan. TSScheduleOnThread() seems perfect and much more powerful. Any use cases you guys can figure for scheduling a cont on a specific different thread? For scheduling on the current thread case, we don't even need a mutex. If we'd schedule the cont with mutex on the mutex->thread_holding, we only need the mutex from the user and don't need to have the new API TSMutexThreadHoldingGet().
2018-08-15 7:29 GMT-07:00 Alan Carroll <solidwallofc...@oath.com.invalid>: > I am fine with extending "TSThreadPool" to include a "this thread" value.. > I don't think it breaks the name, it's just specifying a pool of size 1 > :-). > > For Otto's suggestion, I'd go with adding a new API type, "TSEventThread". > This, in contrast to TSThread, would represent a thread that has an event > loop and which therefore can handle event scheduling. A TSThread does not > have this capability in general. Additional API could be built around this, > such as "TSEventThread TSThisEventThread()" which returns the current > thread. Then you can easily implement what Otto requested, > "TSScheduleOnThread(TSCont, ink_hrtime, TSEventThread)". The original > request would then be "TSScheduleOnThread(contp, 1, TSThisEventThread());". > We might want to add "TSMutexThreadHoldingGet" which gets the thread > holding a mutex. For the kind of scheduling you guys are discussing, this > has proven quite handy in the core. I can work on a write up if you think > this is a reasonable direction to go. > > On Wed, Aug 15, 2018 at 1:57 AM Otto van der Schaaf <osch...@gmail.com> > wrote: > > > +1 for APIs that allow scheduling on an arbitrary thread > > > > On Wed, 15 Aug 2018 at 03:37, Kees Spoelstra <kspoels...@we-amp.com> > > wrote: > > > > > +1, we currently have it implemented but did not come around to make a > > pull > > > request and a proposal. > > > > > > Some remarks, instead of current thread we should be able to schedule > on > > an > > > arbitrary thread (*OnThread) > > > > > > This can also improve performance by preventing thread jumping and > > provide > > > simpler concurrency because there is no concurrency :) > > > > > > Not having access to source code, but I recall the change not being > too > > > big, it is mostly adding the thread to some calls. > > > > > > If people are interested I'll try to provide a pr in the next two days > > > > > > > > > On Wed, Aug 15, 2018, 08:58 zzz <z...@apache.org> wrote: > > > > > > > Hi, team, > > > > > > > > The background here is we'd like to clean up a thread local cache > after > > > > some timeout. Unfortunately, we're lacking an API to schedule a > > > > continuation to the current thread. > > > > > > > > There are two ways I can think of to achieve this. > > > > One is a pair of new APIs *TSContScheduleToCurrentThread(TSCont > contp, > > > > ink_hrtime timeout) *and* TSContScheduleToCurrentThreadEvery(TSCont > > > contp, > > > > ink_hrtime every).* > > > > Or we can append the TSThreadPool enum with a new entry called > > > > *TS_THREAD_CURRENT > > > > *and add the logic into *TSContSchedule() *and > *TSContScheduleEvery(). > > * > > > > The issue with the latter solution is *TS_THREAD_CURRENT* doesn't > quite > > > fit > > > > in TSThreadPool. If we change TSThreadPool to some more proper name, > > the > > > > change will not be backward compatible. > > > > > > > > Please feel free to share your insights. Any ideas would be much > > > > appreciated! > > > > > > > > > > > > Thanks, > > > > Zizhong > > > > > > > > > > > > -- > *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 >
