Hi Scott:
I was looking at ThreadPool.reclaim today and I found something that just
doesn't look right.
/**
* Called by an EThread to indicate that it has finished processing
* a job and may be reclaimed by another job.
*
* @param e The EThread to reclaim.
*/
public boolean reclaim(EThread e) {
boolean rv=false;
if (maxThreads == 0 || threads.size()<maxPoolThreads) {
// LOOK HERE ---------------^
threads.push(e);
rv=true;
}
synchronized(threads) {
threads.notifyAll();
}
return rv;
}
Shouldn't the check on threads.size() be against maxThreads?
I couldn't figure out what the intent of maxPoolThreads is.
The value is hard coded to 5 in the ThreadPool constructor call in Core.Core.
If I am following the current implementation of ThreadPool correctly, it
looks like you will start out with maxThreads Ethread and discard them
as they are used up, until only maxPoolThreads (5 in the current code) remain.
This would explain the SendFailedExceptions when making lots of concurrent
connections, that I reported earlier on this list.
Also, it looks like the entire method should be synchronized on threads,
otherwise there's a race condition.
-- gj
--
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
