>
> 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.
> 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.
Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20011018/e09e1436/attachment.pgp>
