BenBE

> Hmm, I just realised, I forgot to remove the `patch` file that came from: > > `https://github.com/htop-dev/htop/issues/1193#issuecomment-1454474359` > > It's now gone, and I have rebuilt htop. > >...

The large number of red (terminated) marked processes and the specifics I gather from your described work-load hints at the possibility that we're dealing with loads of short-lived processes here,...

Have you tried reading the resource section from the binary in question directly? From there parsing out the actual Bitmap resource is kinda straight forward.

Doesn't this effectively make `LFS_CONFIG` and `LFS_DEFINES` be the same (except for the latter also defining the default utils too)? A better implementation would be to have `LFS_CONFIG` work just...

I agree with @fasterit here. Please shorten that formatting logic. What can (and probably should) be done is reordering things to work like: 1. Short static buffer for the signal...

I don't think we should start putting C++ code in htop. The C implementation you linked also has some quirks which aren't quite right (aside from missing the format attributes,...

I think that GCC14 only warns about one of those is a bug due to a missed warning. So when we are fixing this it will need to be both....

I can live with that. And for nested signals we could just go ahead and ignore the second signal. ``` // Imagine this being all atomically sound … atomic_int8_t signal_nested...

> > I don't think we should start putting C++ code in htop. The C implementation you linked also has some quirks which aren't quite right (aside from missing the...

Had a quick look at the API: Looks good so far. Probably some suggestions: * `lsof_file_access_mode`: Be explicit about the value of the modes. Maybe `_NONE = 0`, `_READ =...