On Fri, Nov 01, 2002 at 12:20:37PM -0000, Dave Hooper wrote: <> > Why not just create a pool of idle threads at startup and keep it that > way? Configure it through experimentation. Idle threads (really idle, > that is) don't place much of a drain on resources, but creation/destruction > (of anything, in general) is always going to place a load on anything. > Create n threads. Leave it that way. Threads then get selected from the > pool, do some freenet-requesty type stuff, get deinitialised and thrown > back into the pool.
I was replying to a message saying that idle threads did draw significant resources, so obviously opinions are divided there. Also, as has been noted elsewhere, we are already pushing certain hard limits (256 threads max in bash for example). Of course, what you describe is more or less exactly what FastThreadFactory does (it creates threads on demand at first, but that should only matter for the first few minutes), so if that is what you want it's there for you. > Something about the idea of trying to dynamically balance the number of > threads vs. the number of idle threads whilst not using a metric that takes > into account cpu or memory load seems like a very wrong approach to me. > Correct me if I'm wrong though. System speed is indirectly taken into account since slow nodes start rejecting and thus dispatch less jobs. -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
