> -----Original Message-----
> From: Carlos Quiroz [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 03, 2001 1:15 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ThreadPool
>
>
> Opinions, Comments?
>
Well, this is a sizable request but since you asked ;-)...I would like a
ThreadPool API to be a facade to an underlying pluggable implementation.
This is kinda similar to some suggestions in other posts regarding the
Logging API, that the Logging API be a facade to an underlying
implementation that could be based on Log4J or the new Logging API in JDK
1.4.
This is also similar to the JNDI API, JDBC, etc..
My reason for wanting an API with a SPI (service provider interface) is that
in the past I have written code that used a homegrown thread pool. Then
later, when trying to reuse the code in another project with its own thread
pool, the code had to be rewritten for the project's thread pool. Then
rewritten again when I tried to create an Enhydra module (which has its own
thread manager). And so on and so on.. There are homegrown thread pools
all over the place, everybody has one of thier own.
For this reason I think a "pluggable" thread pool manager would be a good
thing.
If you are planning to design a very sophisticated threading API then allow
for some methods to throw an UnsupportedOperationException, so that very
basic thread pool implementations can be reused. Similar to the Collections
API use of UnsupportedOperationException.
Anyway, just a suggestion...
ted stockwell
