On Monday 12 February 2001 09:32, Scott wrote:
> Yeah, that seems right. There should be a ThreadGroup containing the
> threads, and runningThreads should be the number of active threads in that
> group minus those in the thread pool.
>
> Attached is a patch. I've updated the experimental tree if someone can
> patch this against the stable tree.
>
> Scott
Hi Scott:
This doesn't look quite right. How do the java.lang.Thread objects managed
by the ThreadPool ever get into the poolGroup ThreadGroup?
It looks like tg was omitted from the superclass constructor arguments
in ThreadPool.ThreadPool.
See comments in code snippet below.
-- gj
/**
* Creates a ThreadPool with a fixed number of concurrently
* executable jobs. This also allocates a job queue, so that
* new jobs can be inserted in a non-blocking manner even if all
* maxThreads threads are occupied. This ThreadPool allows up to a
* total of maxJobs running and queued jobs.
*
* @param tg The ThreadGroup to use for the pool and all it's
* children.
* @param maxThreads The number of jobs that can be active at any
* one time.
* @param maxJobs The maximum total number of allowable jobs. {@link
* run run()} returns false to turn away additional jobs past this point.
*/
public ThreadPool(ThreadGroup tg, int maxPool, int maxThreads,
int maxJobs) {
super("ThreadPool");
// ^--- LOOK HERE.
// Shouldn't this be:
// super(tg, "ThreadPool");
//
setDaemon(true);
this.poolGroup=tg;
jobs=new BlockingQueue();
threads=new BlockingStack();
this.maxPoolThreads=maxPool;
this.maxThreads=maxThreads;
this.maxJobs=maxJobs;
fillThreadstack();
}
--
Web page inside Freenet:
freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage//
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://www.uprizer.com/mailman/listinfo/devl
