I forgot to mention in my earlier post that in his concurrency book Doug
Lea also endorse the use of the JCSP library (although the licensing
issues with may indeed be murky).
Roy
--
Roy Wilson
E-mail: [EMAIL PROTECTED]
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 12/29/00, 1:41:33 AM, [EMAIL PROTECTED] wrote regarding Re:
Licensing / Source Question:
> Hi Dan,
> > In the course of some work I've been doing on Tomcat, I've been
> > thinking about using a Thread Pool. There is currently a bunch of code
> > doing this in both TC 3 and TC 4, but, no surprise, it's extremely
> > difficult to understand and/or extend.
> Well, it is a big surprise - I thought TC 4 is perfect, only TC 3 is
> difficult to understand and need refactorings :-)
> > Doug Lea, author of Concurrent Programming in Java, has written a set
> > of concurrency utility classes, including a very nice-looking ThreadPool
> > ("PooledExecutor") implementation, and some good "Channels" for
> > communication between threads. He documents these at:
> I looked at the code - it's really nice. And what got me really excited
> was that by using it more code could be shared and reused in 3.x and 4.x
-
> as long as both use a common collection of shared utilities it'll make my
> life much easier ( and not only mine ).
> Now, for the negative side:
> - it's not JDK1.1 - but that's not a big problem, as long as the old
> thread pool and modules are around for the poor souls using 1.1.
> Since they use Runnable it'll be easy to use the old pools for 1.1 and
the
> new code for 1.2+
> - do you want to check in all the code ? It isn't bad, but maybe it would
> be a better idea to check in only a subset - or move the utils in a
> different top-level directory.
> - maybe an idea would be to ask the author - maybe he would like to
> contribute it as Apache code.
> - my feeling is that as functionality it doesn't do much more than the
> current thread pools - and one thing less. The interface used in TC3
pools
> ( ThreadPoolRunnable ) allow to maintain and pass some per/thread data,
> that allow better recycling the objects. The alternative is to use object
> pools, but that may be a bit slower ( just a bit - so it's not a big
> problem either).
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
