>>> 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.
>
>I think we could create a ThreadPool interface which defines both methods
but implementors could decide id they implement only one or both. When you
create the pool from the factory you get to know what kind of pool are you
using
>
>.
>
>What I wouldn't use is another Executable interface, I'd just stick to
Runnable. What does the Executable interface offers?
Basically the ability to throw exceptions. ThreadPools are also used for
Task based APIs (see ant or util.concurrent mentioned a few days back) or
when crossing protection domains (see Enhydra or Avalon/Phoenix) which need
the ability to throw exceptions. Without it you end up with ugly hack
wrapper classes that cache store and transmit exceptions - been there, done
that ;].
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 |
*-----------------------------------------------------*
