The number of idle threads is not as easy a problem as it seems. I wrote QThreadFactory exactly so that it shouldn't leave idle threads lying around: It uses a seperate process to service the pool of idle threads, creating new ones if the size falls below a threshold, and destroying some if the it gets too large. In both cases it leaves the idle threads at a value halfway between the two threshholds.
At first I set the minimum number of idle threads to 0.1 of number running, and the max to 0.5. But what I noticed was that as my node was getting overloaded, it was destroying far to many threads using this strategy, making many thousands of new threads per hour. This was why I asked people to try FastThreadFactory (negative threadlimit, which never destroys idle threads at all), in the hope that this was the actual source of the slowness. It doesn't seem that it was, but I still set up the max threshhold to 1.0 of the running threads - which seems to be working better, making the average number of jobs per thread 70-100 or so (which means a couple of hundred threads destroyed/created every hour) but of course it means a much higher tolerance for a large number of idle threads lying around. Of course, I'm just stabbing in the dark here. If there are any computer scientists who can say how this should be done I'm all ears. (And no, "stop using so many threads" is not an option.) On Fri, Nov 01, 2002 at 10:31:22AM -0000, Dave Hooper wrote: > > I also have a complaint to whoever said that 100 > > idling threads is harmless. > > Not on windows it isn't, certainly not in java on > > windows. Threads are rpocesses and have horrible > > overhead. > > As far as I'm aware, all the cool thread / fiber / io completion management > available in win32 isn't accessible from Java (unless someone can point me > to documentary evidence to the contrary that states clearly the particular > (portable) Java code needed to set up a Win32 IOCompletionPort) > > Threads on Java on Windows have horrible overhead but, as I see it, that's > the JVM's fault, and not really a fault of Java itself. A native Win32 > application can happily spawn 100+ threads and not get bogged down in its > own underwear. But for I/O management, having millions of most-likely-idle > threads is NOT the way to go (certainly on Win32 anyway, because there's > far better ways to do things). > > d > > > > _______________________________________________ > devl mailing list > devl at freenetproject.org > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
