> > 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 ThreadPool may have a default priority level, which is assigned by
default, but you could override it with a dispatchTask(runnable,
Thread.HIGH_PRIORITY), When the thread is released it will return to its
original pool's priority. In that way you could use pols with a default
priority such as highPriorityPool or backgroundPriorityPool, and still be
able to modify the priority if required.
> > I'd rather allow an optional "priority" parameter but even this one
> > should only be very rough (as in HIGH, NORMAL, LOW, IDLE).
In principle I'd keep with just the JDK's MAX_PRIORITY, MIN_PRIORITY,
NORMAL_PRIORITY
> 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 )
>
> ...
> }
> ...
> }
I agree, I'd prefer something as simple as possible, but I'd still allow the
possiblity for setting name. In particular this would make logging easier,
since many logging packages (log4j, for instance) allow thread name logging
