Kadaitcha Man wrote: ⤴Sat Aug 01, 2020 6:58 am
I think it's an hilarious slip up.
It's not (really) a slip up. See that report smurphos linked to just above your reply: it's an essentially intentional change made in the context of Firefox's upcoming integrated about:processes process manager:
https://www.ghacks.net/2020/05/11/this- ... processes/.
While useless on Linux --- just run
top,
ps or whichever GUI-wrapper/version of such your desktop environment feels useful --- said bit of industry-blur may supposedly be useful on operating systems designed to hide as much detail from the user as possible such as, in that order, Mac OS and Windows. Or not, I use neither, but from smurphos' link it's in any case not an issue on either of said platforms; it's specifically "Linux" rechristening of the process to equal its main thread that is the issue here, as for example it was for
https://nikhilism.com/post/2018/linux-main-thread-name/
In this "Linux" is to be read as "procps" and if I'm not mistaken (well might be...) I in fact remember this conversation from 10+ years ago in
its context and in the other direction: various tools that were at least back then common, and from a time that threading wasn't, needing this to give sensible output
then. Can't quickly find very specific reports/discussions from back then again but e.g. this will be related:
https://gitlab.com/procps-ng/procps/-/wikis/faq
Why do ps and top show threads individually?
The 2.4.xx kernel does not provide proper support for grouping threads by process. Hacks exist to group them anyway, but such hacks will falsely group similar tasks and will fail to group tasks due to race conditions. The hacks are also slow. As none of this is acceptable in a critical system tool, task grouping is not currently available for the 2.4.xx kernel.
I.e., this process/mainthtread name issue seems likely a leftover from days of backwards compatibility with 2.4 kernels and as such, likely at this point really only to be seen as a "bug" or oddity at the very least of "Linux". One which would be unlikely to at this point be fixed, given that
now various tools will have gotten to depend on or be feared to depend on this behaviour, but still.
The Firefox bug has been marked wont-fix for 79 and fix-optional for 80. This issue will probably perculate up to "procps" and it's sort of interesting to see where it will go from there...
