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 wrote:
> Thanks, Fei Deng, glad to hear the good news! Looking forward to the ne
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 :
> I wait, with bright eyed anticipation, for the documentation for this!
>
> On Tue, Aug 21, 2018 at 9:47 AM Fei Deng wrote:
>
> > I'm looking into this right now. Already have t
I wait, with bright eyed anticipation, for the documentation for this!
On Tue, Aug 21, 2018 at 9:47 AM Fei Deng 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, 2
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
wrote:
> As a quick response, it sounds like most of your issues would be addressed
> by thread affi
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
On Thu, Aug 16, 2018, 20:39 Alan Carroll
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 i
"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
Adding to that, we might need have to look into this:
- getting the TSEventThread from a vconn, txn, ssn instead of implicitly
trusting that the current thread is relevant?
- moving a client vconn to a certain thread (we've seen that the thread
jumping in plugins can really kill performance with p
A TSEventThread API makes sense to me; maybe Kees has something similar in
the
implementation for XXXOnThread() he mentioned.
Regardless, it sounds like this would allow fine-grained control of where
code associated to a
continuation is executed, which would be great as far as I am concerned.
Otto
In the core, when a continuation is scheduled on a specific thread that is
not the current thread, it's because there is a locked object with the lock
held on another thread, and the goal is to have the continuation run on
that thread. This can help gather interacting objects on the same thread
whe
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->
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 eve
+1 for APIs that allow scheduling on an arbitrary thread
On Wed, 15 Aug 2018 at 03:37, Kees Spoelstra 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
> a
+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 concurren
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
15 matches
Mail list logo
