On Thu, Oct 18, 2001 at 10:46:50PM -0700, Scott G. Miller wrote: > > > > Well, I'm not entirely sure how the ThreadPool works, but I thought that > > the pool number was the number of threads that were always kept alive > > (except I guess "minPool" would be a better name for that I guess), the > > maxThreads number was the maximum that could ever be alive, and I don't > > see the need to enqueue any jobs at all (there is no sense in > > leaving jobs hanging we don't have threads for, all new Threads except > > connections come from the Ticker). > > There are three values, as you guys know. minPool states the number of > threads kept running. If a thread is returned to the pool and there > are more than minPool threads already in the pool (not being used), then > that thread is allowed to terminate. > > maxPool is the maximum number of running threads allowed. > maxJobs is the number of jobs allowed, including running jobs and queued > jobs.
Well, if you look in the code you'll see that you called these properties maxPool, maxThreads, and maxJobs - which is a little confusing. Also, to be annoyingly picky, as a matter of good design, poolSize, maxOverFlow (maxPool - poolSize), and maxQueue (maxJobs - maxOverFlow) would have better, since that avoids the runtime error of not keeping the next bigger than the former. > > It seems logical to me that we keep an active pool of about half the > > allowable threads - why would we only keep 5? > For system resource reasons. Theres absolutely no reason to keep 60 > threads running. You only need to keep enough running to eliminate the > overhead of thread creation. So if one of idle threads starts being used, the Pool will be filled up to minPool again? All the same - we do not need or want a job queue there. -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
