At 12:29 3/5/01 -0700, Earl Hood wrote:
>On May 3, 2001 at 12:46, "Michael Gerdau" wrote:
>
>> >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.
>>
>> 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.
>>
>> I'd rather allow an optional "priority" parameter but even this one
>> should only be very rough (as in HIGH, NORMAL, LOW, IDLE).
>
>An option is to provide access to the ThreadGroup object to allow
>properties to be defined for all threads in the pool. I did this for
>a ThreadPool class I wrote. The ThreadGroup can be retrieved before
>starting the pool inorder to set any properties desired (like priority).
>
>A more general approach, that was already mentioned, is to allow one to
>specify a custom ThreadFactory so if one needs to set properties of the
>threads used, they can create a ThreadFactory implementation to do it.
Unfortunately that doesn't cut it as usually you need to have Thread
implement a particular class so it replaces itself back in pool after it
has done a run() on it' client. The way I am just about to redesign the
Avalon thread pool is as follows
interface ThreadPool
{
void executeAndWait( Runnable work ) throws ThreadException;
void executeAndWait( Executable work ) throws ThreadException;
ThreadControl execute( Runnable work );
ThreadControl execute( Executable work );
}
class ThreadException
{
...
Throwable getRootCause() { ... }
...
}
interface ThreadControl
{
void interupt() throws Exception;
boolean isValid();
boolean isFinished();
Throwable getThrowable();
}
//Method gets called for thread hook right before you dispatch work
interface ThreadHook
{
void setupThread() {}
}
executeAndWait is useful when you are using the pool to cross
thread/protection boundaries (Very very useful in writing software like
tomcat/james/Avalon-phoenix).
execute returns a control so you can control all the important features of
thread directly.
ThreadHook.setupThread() is called right before a set of work is dispatched
and usually used to set name of thread, contextClassLoader and any other
thread local variables.
All other thread features (ie priority, whether thread is a daemon thread,
etc) are determined by pool.
I haven't found any places where the above design won't work - what do you
think about it?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]