Darwin: scan thread information

[cgzones]

Origin: https://github.com/hishamhm/htop/pull/848

Closes: #542

/cc @robaho @Karsten1987 @fasterit

[natoscott]

@cgzones looks good to me. Might be worth setting 'isThread = false;' in DarwinProcess_new instead of relying on the calloc there, for code clarity. If that's not preferred and calloc is OK - which is fine by me - there's some other initializations-to-zero in that function that could be removed.

Also I wonder about the taskAccess field (not from your new code, but related to threads) - it seems like this field might cause incorrect behaviour if htop samples a process before it creates any threads - if it only creates threads later in its life, those threads would never be counted because this flag was set first time through. If thats the case, I think it could be safely removed - it appears to be an optimization only, AFAICS.

[BenBE]

Just a small tip: Press Esc once to hide the process list cursor. Also Tree Mode might be of help to group the threads optically below their parent.

[BenBE]

Please check if this also fixes #622.

[Karrq]

I checked out this lcoally and built it but I still don't see the threads, even running the tool with sudo.

On MBP M2 Ventura 13.3

[BenBE]

Have you checked that your configuration has display of userland threads activated.

[Karrq]

Yep I had unchecked "Hide userland process threads" and also tried toggling it on and off with H just to make sure and I don't see any change in my output, and I also tried tree/list mode... I was trying to look at the threads of a specific process that I'm interested in as Activity Monitor only reports the number of threads (8), so I'm sure there are threads for that process.

(btw v3.2.2 also doesn't show threads per process, but I can see the total number of user threads under tasks)

[BenBE]

Okay, strange. I can confirm this is somewhat strange behaviour. @cgzones Can you check your patch again?

[cgzones]

Recent versions of MacOS limit the access to foreign threads via thread_info(). I am not aware of an alternative API. It might work though with a signed binary running as root (not tested).

[hashok]

I've compiled htop from this branch on MacBook Pro Max M2 running macOS Ventura 13.5.1 (all updates installed as of 30-Aug-2023) and I do see user land threads 🎉 , but only when running sudo htop. I have not signed the htop binary indeed. So it's definitely an improvement over the current htop version 3.2.2 from Homebrew.

Here are worker threads of the perf_test tool shows. Also note alignment issues of | in the tree view. But that's a different issue indeed.

[emadpres]

I also just compiled cgzones:darwin_threads on M2 Max (McaOS 13.5.1), and I can confirm the threads are shown (only with sudo).

Not sure how relevant, the followings are broken:

1. refreshing
2. Tree structure (see |s)
3. scrolling

here is a side-by-side comparison of htop v3.2.2 with the compiled branch:

[polluks]

Works on macOS 14.0 @emadpres Your PID is really high, too high for the tree.

[emadpres]

Works on macOS 14.0 @emadpres Your PID is really high, too high for the tree.

What do you mean it's too high? That's what I get.

[BenBE]

@cgzones Can you rebase? What'S missing to push this along?

[polluks]

@emadpres I was talking about the width: Your PID have 7 digits but htop is fixed for 5 digits. This seems to be a bug. However your system should not use 3 million processes in 4 days...

[cgzones]

What's missing to push this along?

Testing: check all threads are displayed, no memory is leaked, tree glitches.

(Only compile tested the latest rebase.)

[cgzones]

LGTM. No obvious memleaks.

Minor nitpick: Neither identifer_info_count nor extended_info_count are used or checked after their assignment through the call to thread_info, but access to at least the first item of the returned arrays is assumed.

The output parameters identifer_info and extended_info are not arrays, see https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_info.html for API details.

[BenBE]

LGTM. No obvious memleaks. Minor nitpick: Neither identifer_info_count nor extended_info_count are used or checked after their assignment through the call to thread_info, but access to at least the first item of the returned arrays is assumed.

The output parameters identifer_info and extended_info are not arrays, see https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_info.html for API details.

Ah, I see. So basically buffer sizes. In that case, at least checking for "a whole item was returned" should suffice. But as mentioned, that is somewhat nitpicky.

[BenBE]

@cgzones Can you have a look at the PID auto-sizing issue? Likely missing the width update call for that column. Bugfix for that should get its own PR.

@fasterit Can you take a look at this PR, so we can push it along?

[dundee]

Any update on this? Would be great to see threads on Mac!

[fasterit]

@dundee: Did you test the cgzones:darwin_threads branch?

[dundee]

@fasterit Yes, it works fine for me (using sudo).

[findepi]

@cgzones @BenBE thanks for this PR! Small question, which version this is/will be available in? latest version from brew is 3.3.0 and doesn't show threads (even with sido). Current main branch built from source shows threads on my Mac (when run with sudo). The from-source build also reports version as 3.3.0.

[BenBE]

If your from-source build reports 3.3.0 you should re-run autogen.sh.

That aside: from the commit mentioned in the merge commit you can determine exactly when this landed, but I'd guess it's highly likely this was after 3.3.0 was released; thus this is probably not included in any release yet. Have a look at the milestone of this PR to check for which release it is planned.

[findepi]

@BenBE apologies. i checked version wrong. my from-source build is 3.4.0-dev-3.3.0-144-gdb73229.

Have a look at the milestone of this PR to check for which release it is planned.

oh, i didn't notice that, but that's so nice. looking forward to 3.4.0 release then. thanks!