Cool refactoring!
+1
Peter
Am 13.08.2009 um 22:07 schrieb Filip Hanik - Dev Lists:
Here is why I think its good
1. Current pools can't shrink, so when peak has been hit, that's
where were at
2. Current pools are unfair, synchronized (workers)
{ workers.wait() }, executors are a bit more f
On 13.08.2009 22:07, Filip Hanik - Dev Lists wrote:
> Here is why I think its good
>
> 1. Current pools can't shrink, so when peak has been hit, that's where
> were at
> 2. Current pools are unfair, synchronized (workers) { workers.wait() },
> executors are a bit more fair since they only hold a l
2009/8/14 Filip Hanik - Dev Lists :
> On 08/14/2009 10:48 AM, Costin Manolache wrote:
>>
>> +1 - Executor seems the right interface, didn't exist when workers were
>> started - ifanyone needs the pool behavior it can probably be implemented
>> as
>> an Executor.
>>
>> I assume you'll have some way
On 08/14/2009 10:48 AM, Costin Manolache wrote:
+1 - Executor seems the right interface, didn't exist when workers were
started - ifanyone needs the pool behavior it can probably be implemented as
an Executor.
I assume you'll have some way to configure what kind of executor ?
Yes we do, th
+1 - Executor seems the right interface, didn't exist when workers were
started - ifanyone needs the pool behavior it can probably be implemented as
an Executor.
I assume you'll have some way to configure what kind of executor ?
Costin
On Fri, Aug 14, 2009 at 1:30 AM, Mark Thomas wrote:
> Fili
Filip Hanik - Dev Lists wrote:
> Here is why I think its good
>
> 1. Current pools can't shrink, so when peak has been hit, that's where
> were at
> 2. Current pools are unfair, synchronized (workers) { workers.wait() },
> executors are a bit more fair since they only hold a lock for a short
> per
