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
?Currently all the attempts_timeout values are in seconds. We have seen some
issues where we believe being able to have a finer granularity over this may
help alleviate some problems. Also for live streaming video in 2 second
fragments a 1 second timeout does not provide as much control. So pro
Would it perhaps be a good idea to add a _ms suffix to the config
variable names of timeouts that are not seconds?
On Wed, Aug 15, 2018 at 12:15 PM, Zelkowitz, Evan
wrote:
> ?Currently all the attempts_timeout values are in seconds. We have seen some
> issues where we believe being able to have
I thought about that, but I think that's not the best approach because we
want to make it more general, so it can have seconds or milliseconds. OTOH
maybe that will have to wait until we YAMLize it. If we could do anything,
I'd add the type "TIME" vs. "INT" and "STRING" and have that be seconds
unl
Or jump off.
On Wed, Aug 15, 2018 at 1:27 PM, Alan Carroll
wrote:
> I thought about that, but I think that's not the best approach because we
> want to make it more general, so it can have seconds or milliseconds. OTOH
> maybe that will have to wait until we YAMLize it. If we could do anything,
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->
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
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
