This seems to me like a very inefficient way to do things. Using a million threads to handle what I assume is an I/O bound problem is bad enough (although I realise why it's a necessary evil, and I'm fully prepared to accept that in the case of freenet it may be compute bound problem because of the encryption), but adding thread creation / destruction into that soup?
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. 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. d _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
