From: "Michael Gerdau" <[EMAIL PROTECTED]>
> >I'd rather have different ThreadPool instances for different 'names'.
> >
> > importantThreadPool.dispatch( aRunnable );
> > backgroundThreadPool.dispatch( anotherRunnable );
>
> I doubt that it would be a good idea to try to "outwitt" the OS's
> taskmanager w/r to clever allocation of processtime.
Agreed.
I just meant to use different ThreadPool instances for different things
rather than complicate the dispatch() API with a 'name' parameter.
An importantThreadPool may have more threads configured for it than a
backgroundThreadPool which may have just one (or none). Or internally the
Thread objects may have differing priorities but that would be an
implementation or configuration detail.
> The only exception might be for realtime-critical applications but
> even then I doubt it would be clever to implement it on such a high
> level.
Agreed - I don't think priority is a big deal - though specifying things as
IDLE or LOW can be useful for background things.
> I'd rather allow an optional "priority" parameter but even this one
> should only be very rough (as in HIGH, NORMAL, LOW, IDLE).
Though I'd rather priority be a property (or implementation feature) of a
ThreadPool rather than an argument in the dispatch API.
I'd rather a developer not have to know anything about such things when they
are dispatching a Runnable object to a ThreadPool. So the dispatching API is
as simple:-
public class ThreadPool {
public void dispatch( Runnable runnable )
...
}
...
}
> This would remove the potential need for a multiplexer to distribute
> resources as well and thus keep things simpler.
Yes. I'm not sure a multiplexer is much use really, I just wanted to keep
any multiplexer-like behaviour out of ThreadPool, so I introduced the
Multiplexer object as a bucket to catch such features if anyone thinks
they'd be useful.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
