+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 <ma...@apache.org> wrote:
> 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
> > period
> > 3. Reduce duplicate code
> > 4. Executors provide more flexibility
> > 5. I have not found a performance difference anymore
> > 6. Async implementation becomes much easier, since
> > AsyncContext.dispatch() is easily handed off to an executor and
> > releasing application thread. Otherwise we have to add an executor on
> > top of the existing thread pool, which is doable, just not pragmatic
>
> If you mean give each connector it's own executor by default and the
> option to use a shared executor then +1
>
> For the record, it was point 6 that made the argument for me.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
