I now understand the algorithm, but I don't understand why is the way it is.
Consider one of these objects configure with a handful of threads and
a pretty big queue.
When the first request comes in, the object creates one runner. It
then won't create a second runner until the Q reaches 1/2-full.
If the idea is that we want to pile up 'a lot' (1/2-of-a-q) of work
before sending any of it, why start that first runner?
On Wed, May 29, 2013 at 2:45 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> Ah. So now I have to find some other explanation of why it never
> creates more than one thread, even when I make a very deep queue and
> specify 6 threads.
>
> On Wed, May 29, 2013 at 2:25 PM, Shalin Shekhar Mangar
> <shalinman...@gmail.com> wrote:
>> On Wed, May 29, 2013 at 11:29 PM, Benson Margulies
>> <bimargul...@gmail.com>wrote:
>>
>>> The comment here is clearly wrong, since there is no division by two.
>>>
>>> I think that the code is wrong, because this results in not starting
>>> runners when it should start runners. Am I misanalyzing?
>>>
>>> if (runners.isEmpty() || (queue.remainingCapacity() < queue.size() // queue
>>>
>>> // is
>>>
>>> // half
>>>
>>> // full
>>>
>>> // and
>>>
>>> // we
>>>
>>> // can
>>>
>>> // add
>>>
>>> // more
>>>
>>> // runners
>>> && runners.size() < threadCount)) {
>>>
>>
>>
>> queue.remainingCapacity() returns capacity - queue.size() so the comment is
>> correct.
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
