avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: ThreadPool
Date Fri, 04 May 2001 00:21:34 GMT
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

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?



| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message