Hacker News Reader

Comment by fredsted | Hacker News Reader

One of the first things I do when launching htop on a new box is to disable threads. The current way of showing threads by default is untenable because some programs launch hundreds of threads, making it hard to get an overview of a system unless you make the terminal size very large.

I appreciate the author wanting users to discover a program running amok and producing a bunch of threads (anecdote: I've never seen it happen), but there's a bunch of ways to solve it from a UX perspective:

* make threads collapsed by default

* add a column showing the number of threads a process has

* add the threads toggle to the bottom bar for easy discovery

* add a prefix to all threads, e.g. [THREAD]

All of these are a lot more obvious than the color green.

The authors story of having users ask him why processes are green is simply an indication that the user interface is hard to understand.

View on HN

>some programs launch hundreds of threads

I feel like that's the crux of it. If I'm reading htop right I'm at ~140 tasks* and ~1000 threads.

The itch.io app that is hanging out in my system tray is currently sitting at ~200 threads by itself.

It's not helpful or educational to have pages of identically named threads especially when everything is only getting more multithreaded.

*and that's for my Cinnamon desktop, three firefox windows, thunderbird, steam, itch, a terminal and htop, lord knows if I was actually doing something with my computer.

I'm so sick of people telling me something is using some ridiculous GB of RAM because they've added up all the threads' memory in htop

We really need better tooling for this. It is possible but you have to parse snaps which I think is expensive ish. Would be great to get something useful info commonly used tooling though.

typo: by "snaps" i meant /proc/PID/smaps

Pointing out the error in their reasoning by noting their sum exceeds the RAM their computer actually has usually works well.

He he. I came within a hair's bredth of doing exactly that.

Saw this article, installed htop, ran it - all in pre coffee morning fog

OMG A dozen firefox threads each using 10%! ....

Even in my 10% early morning function I realised, but I get your point.

Me too, I really hate that! I wish they'd stop making that very obvious and simple mistake in reasoning!

...just so that _I_ can know that you know what you're talking about, can you elaborate on what that obvious mistake (which I clearly know about) is?

Dropping the joke - I assume it's that threads share memory in some way (so that the total consumed is not the sum of each consumption), but a. how and why, and b. why isn't it trivial for htop to represent that "correctly"?

Threads usually share address space. There's no way to know particular thread memory usage, so htop just duplicates same information for every thread.

Got it, thanks.

> There's no way to know particular thread memory usage

This sounds like the sort of statement that is self-evident to folks with a CS education (I studied math, and all my CS/programming knowledge is self-taught). I'll add that to my _long_ backlog of things that I should research to get over my imposter syndrome :)

For most operating systems, threads each have their own stack space, and (if supported) thread-local storage, but share heap, constants (.bss), and static variables (.data). It's impossible to say exactly what resources a given thread is using from those shared resources, so htop just includes them all, for every thread.

Much appreciated, thank you!

I'm not aware of any other user scenario where launching htop and threads showing makes sense. Threads are details, while most people watch for OS processes first. That they are green doesn't help anyone if there's nobody to ask why or colours don't show properly. This is misguided newbie fixation that alienates those users who just need a reliable tool with sane defaults. Just another user feedback.

This is a lesson to all of us, that we might have very good reasons, but there's still a chance to be wrong about things.

While the author's reasoning mostly resonates, I agree with you and disagree with them on this particular point. For a typical user of htop, what matters is not "a process" or "a thread", but a killable unit. A piece of software that, should it misbehave, I can kill and possibly restart later. Killable units are almost always individual processes. Almost never threads - I can't think of a piece of software that can recover from having its random thread killed. Sure, I like to see threads - particularly in tree view - but I think the default should still be to hide them (with a more discoverable toggle than just Settings screen).

Yea, the reasoning isn't bad and try to be user-focused. It's just that the end result might not be real-life optimal, for most users or most use cases. You see this alot with UX. Sometimes it breaks new ground (iPhone), but it can also make things really hard to utilize properly (mobile interface for everything).

While it doesn't happen nowadays, I did some really weird things to selfcompiled/patched Firefox in the past, including killing tabs via killing threads in htop. But it wasn't obvious which thread was a tab, or if it was a tab at all.

But it worked about two thirds of the times :-)

Second this, killing processes is one of my main uses of htop. Having the interface be optimized for that by collapsing threads by default would be nice.

The bikeshedding in this thread is astonishing. Everybody in the world seems to have a strong opinion about how threads are shown in htop, about the shortcut for them, the default for showing them and their color.

Seems like that's easier to do than a thought about the actual substance of the blog post. Or being grateful that there is such a fantastic tool around, that there is a profound philosophy behind it, or that the original author shared it with us with some pretty good arguments.

But sure, let's keep discussing why shift-H needs to be made into a more prominent entry in the htop option screen.

I've only recently started using htop, and the last task I had to do in it was try to figure out a similar thread problem.

The default UI did not tell me if the threads had 'run amok'. There aren't enough lines on the display to tell whether a process with 10 threads on a normal day is now running 50.

So like you said, I had to turn off threads, then turn on the thread count column (which I never would have found without a search engine/stack overflow).

> * add a column showing the number of threads a process has

FYI the column exists already, but it's not enabled by deault. It's called NLWP, which I assume is short for Number of LightWeight Processes.

As for my own UI suggestions, I would hide threads by default, and stop displaying anything in all the columns of a thread where it's impossible for the cell to be different to its parent.

Maybe in tree mode, have all of a process's threads grouped under an expandable [threads] pseudo-process as well.

Keep a copy of .htoprc with your ssh keys. I have a skeleton /home on my keyring for using various machines with ease.

And everytime one toggles any setting that's is retained over htop restarts like tree view, the file gets edited. And you get diverging files everywhere. Annoyed me very much. Had to write a custom patch to disable some of it.

chmod +i .htoprc?

For the benefit of someone like me who only uses Linux and bash on behalf of myself and the companies I work for and haven't studied it extensively, can anyone here tell me what the i is for?

I wasn't able to find it in man chmod on my machine, DDG failed me, as did Google.

(positive feedback to employees of DDG and Google: whenever I get assigned to the experiment where you show the snippet you thing matches my query it brightens my day, - even if the snippet shows that the result was irrelevant like here "<something about> chmod. I <something about the author>". I think Google used to nail this back in 2007 but anyways, seing the snippet in the front page helps a lot.)

Immutable. The reason you couldn’t find it in chmod(1) is because it’s the wrong command. The correct command (and manual page) is chattr(1).

Oops! Thank you.

`chmod 440 ~/.config/htop/htoprc` did the trick for me. Still an unnecessary annoyance but I'll live.

just replying to myself as I got it wrong, it's chattr +i, not chmod. Sorry! (and thanks to the response below correcting me)

I agree. I like htop a lot but this behaviour is very hostile. Toggling an option at runtime shouldn't overide the static config without confirmation.

Indeed, why oh why is there no way to provide configuration preferences apart from doing so interactively? I would gladly wrap the command to provide it using flags, but no. I would equally gladly edit a configuration file (even if the syntax was wonky), but no. Instead I am left having to remember to set (and reset!) my defaults across users and machines.

Do you mean it's possible to cleanly auto-inject a .htoprc on whatever machine I SSH into?

If so I'd like to learn about the technique

Same. Along with .vimrc and .tmux.conf

You can use rsync or Git for this purpose.

> program running amok and producing a bunch of threads (anecdote: I've never seen it happen)

I've seen it in production. But the simple solution is to cap the number of threads to a reasonable value (ulimits, Kubernetes Pod Security Policy) and add observability for thread count.

A design decision that was perfectly appropriate in 2005 might not make so much sense in 2020. That's okay.

Threading is much more prolific today than it was 15 years ago. Multicore processors are the norm today and there are plenty of great libraries out there which make threading easier, and less error prone than it used to be. It is common today for language libraries to keep thread pools available for executing small concurrent operations. In such a case, knowing what thread was consuming resources probably wouldn't help much in tracking down the issue.

So yeah, I agree with your suggestions. I think they make a lot of sense today. In fact, I bet of the original author were creating htop in 2020, they would make these changes.

Reply on news.ycombinator.com