You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/05/04 02:21:34 UTC
Re: ThreadPool
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ThreadPool
Posted by cm...@yahoo.com.
On Fri, 4 May 2001, Peter Donald wrote:
> >I was thinking of something simpler:
> >
> >interface SimpleThreadPool {
> > void run( Runnable r );
> >}
> >
> >That's all you need in most cases.
>
> true - but when you hit one of the "other" cases you have to throw away the
> pool or do some massive workarounds. Check out the hacks in Avalon that
> were used to get around the above.
The "SimpleThreadPool" is supposed to work for 80% of the cases, and
replace the
new Thread(runnable).start();
( which is what people would do most of the time )
For other cases you may need other interfaces - but why adding complexity
to the simple case ?
Of course, there is space for more than one thread pool, and I think the
"common" characteristic will be the simple interface.
> >On top of this you can add other (optional) APIs ( like ThreadPoolRunnable
> >in tomcat, that saves a hashtable lookup, or any other fancy methods
> >). And of course, the implementation migh have some setters and getters to
> >configure the pool and get info - but that's specific to each
> >implementation.
> >
> >
> >IMHO a big problem with java is that it's far too easy to create
> >interfaces.
>
> Well I believe the opposite ;) - it is far too easy to not use interfaces -
> hence the scattered interdependencies on most products.
Classical case of bad definition of terms, I think we are talking about
different things here :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ThreadPool
Posted by Peter Donald <do...@apache.org>.
At 11:33 3/5/01 -0700, cmanolache@yahoo.com wrote:
>On Fri, 4 May 2001, Peter Donald wrote:
>
>> At 12:29 3/5/01 -0700, Earl Hood wrote:
>> >On May 3, 2001 at 12:46, "Michael Gerdau" wrote:
>>
>> 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 );
>> }
>
>I was thinking of something simpler:
>
>interface SimpleThreadPool {
> void run( Runnable r );
>}
>
>That's all you need in most cases.
true - but when you hit one of the "other" cases you have to throw away the
pool or do some massive workarounds. Check out the hacks in Avalon that
were used to get around the above.
>On top of this you can add other (optional) APIs ( like ThreadPoolRunnable
>in tomcat, that saves a hashtable lookup, or any other fancy methods
>). And of course, the implementation migh have some setters and getters to
>configure the pool and get info - but that's specific to each
>implementation.
>
>
>IMHO a big problem with java is that it's far too easy to create
>interfaces.
Well I believe the opposite ;) - it is far too easy to not use interfaces -
hence the scattered interdependencies on most products.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ThreadPool
Posted by cm...@yahoo.com.
On Fri, 4 May 2001, Peter Donald wrote:
> At 12:29 3/5/01 -0700, Earl Hood wrote:
> >On May 3, 2001 at 12:46, "Michael Gerdau" wrote:
>
> 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 );
> }
I was thinking of something simpler:
interface SimpleThreadPool {
void run( Runnable r );
}
That's all you need in most cases.
On top of this you can add other (optional) APIs ( like ThreadPoolRunnable
in tomcat, that saves a hashtable lookup, or any other fancy methods
). And of course, the implementation migh have some setters and getters to
configure the pool and get info - but that's specific to each
implementation.
IMHO a big problem with java is that it's far too easy to create
interfaces.
Costin
>
> 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org