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
