| |||||||||||||
|
| |||||||||||||
Too many threads?Too many threads?Posted Aug 15, 2003 1:11 UTC (Fri) by giraffedata (subscriber, #1954)Parent article: Too many threads? I've had a lot of discussions about the cost of threads, and I've come to the conclusion that the main cost is the line in the ps display. And the consequent mind space it takes up for those that try to comprehend all the processes in the system. On other systems where threads are organized into a hierarchy and a thousand threads take up one line of ps, people are much more comfortable with 1000 threads. It seems ridiculous to redesign anything just to save lines in a ps display. There must be some easy way to clean up the ps display so we can use the power of threads without feeling like they're costing us too much.
(Log in to post comments)
Too many threads? Posted Aug 15, 2003 15:08 UTC (Fri) by pimlott (guest, #1535) [Link] I've had a lot of discussions about the cost of threads, and I've come to the conclusion that the main cost is the line in the ps display.You're joking, I hope! But you're right that this, like kernel tasks, is best handled in ps. Except the kernel needs to export the necessary information. For kernel tasks, perhaps there could be a "kernel-internal" flag. For combining threads of the same "process", it is less clear what the criterion should be, since Linux gives you so many ways to create related tasks. There are also lots of multi-forking programs that really should be combined in ps. Here's an idea: processes with a common ancestry that have not "exec"ed since they branched are combined by ps. The information to do that may already be available.
|
|
||||||||||||