Auto-scaling will 'never' perform better than fixed one. At best perform
equal I guess (e.g. compare std::vector to normal arrays)
On Thursday, May 8, 2014 5:42:35 PM UTC+2, Ben Noordhuis wrote:
>
> On Thu, May 8, 2014 at 10:26 AM, Kees k >
> wrote:
> > Why the pool size is 4; is it a pragmatic
On Thu, May 8, 2014 at 10:26 AM, Kees k wrote:
> Why the pool size is 4; is it a pragmatic choice?
More or less. The actual number is fairly arbitrary but the reason
it's fixed is that I couldn't make an auto-scaling thread pool always
perform better than a fixed one. I've tried several approac
I was already guessing something like that (uv_loop_t definition), because
setting all intervals to 0.5 sec...
Why the pool size is 4; is it a pragmatic choice?
My workaround is to create only one timerfd with a fixed 1 sec interval
(much more accurate than setInterval, no drift, and does not g
On Wed, May 7, 2014 at 2:01 PM, Kees k wrote:
> Hello all,
>
> I have a difficulty with integrating timerfd worker threads with another
> worker thread. Basically my app has two types of external threads:
> 1. worker thread that sleeps 10 ms ('does some blocking task') and returns
> 2. worker thre
Hello all,
I have a difficulty with integrating timerfd worker threads with another
worker thread. Basically my app has two types of external threads:
1. worker thread that sleeps 10 ms ('does some blocking task') and returns
2. worker thread that is polls a timerfd and returns.
The difficulty s
