Comment 70 for bug 148454

60 useless threads may not use much more memory or consume much more cpu on a modern machine. They do, however, use a significant portion of my resources.

They consume almost 30% of my listing when I run ps -eLf and nearly 50% of my listing when I run pstree -p. They consume keystrokes when I have to add "| grep -v console-kit" to any process listing command I run to get an output that is digestible. And no, "use a pager" isn't an acceptable answer when I want to see a snapshot of what my system is running on one screen, which I can actually do if there aren't 60 threads fobbing up the listing.

Yes, we generally have more CPU cycles and memory than we need most of the time, but screen real estate is still in short supply, as is people's tolerance for obnoxious things.

Even if the console kit is operating properly and is actually designed to spawn this many threads, it immediately looks like a problem and people wonder what's wrong and whether it should be that way. There's no point in people wasting their time trying to figure out if this application is broken or gone haywire- especially when the application doesn't really need 60 threads.

Whether you think it's a "real problem" or not, it is annoying to a lot of people, myself included, and that makes it a real problem. There is no reason this application should need to spawn 60 threads- if they're mostly idle and not really using resources then that just makes it *especially* true that we shouldn't need so many of them. Maybe it was a convenient hack to get the application released quickly, but it shouldn't be difficult (for somebody who understands the code) to change it to run without ridiculous numbers of threads.