GNOME Bugzilla – Bug 134831
add threads support to libgtop
Last modified: 2018-01-10 19:41:31 UTC
Linux 2.6 with nptl changes the way threads vs processes are treated. Threads no longer get their own entry under /proc as they did with linux 2.4 They are now listed under /proc/$PID/task/ gnome-system-monitor / libgtop has not yet been updated to deal with this /proc layout. As a consequence, only processes are listed, never threads even if show threads is selected from the view menu.
procman assumes that processes with the same name and the same memory size are threads. libgtop doesn't know anything about threads : i just deals with PID. Adding thread-related functions in libgtop could be nice. glibtop_threads_entry * glibtop_get_threads(glibtop_threads *buf, pid_t pid); struct glibtop_threads { .flags, .number }; but what would be in a glibtop_threads_entry ? NB : remember that libgtop is system-independant, we're not speaking about adding a Linux only feature.
> NB : remember that libgtop is system-independant, we're not speaking about > adding a Linux only feature. No indeed, but all systems have a concept of threads these days. I guess you're right, libgtop needs to be taught about threads on different systems and present the information in a platform independant way. That would have the bonus that procman would not need to make the platform dependant assumption that different threads get different PIDs.
Right. But what kind of information would you like to get ? thread share mostly everything with their leader process. glibtop could provide a TID list for a given PID, but what else ?
They share all VM stuff and process name/args but have different nice, cpu %, status and TID.
is TID always a integer ? is it as common as PID ? then let's make a list of functions that would be needed : - priority and nice are stored in glibtop_proc_uid. - state is stored in glibtop_proc_state - times are stored in glibtop_proc_time i'd like to introduce 1 new glibtop function (see my 1 answer). I don't know if thread info should be like PID info (look at proc_time, etc that's a lot of statistics). Do we really need all of this ? Which informations are available everywhere ? What about KISS ? .tid .pid .priority .nice .status .utime .stime .rtime .star_time no ? i could also add reserved members / padding so we could extend this later
I'm not an expert at this stuff and I'm not too familiar with the details of what info is avaliable about threads on different OSs. I know that on linux at least, threads have all the same info as processes though some of it is shared with other threads in the process. Solaris and the BSDs are similar. Perhaps it is best to take a pthreads view of things. It has a concept of TID which I belive is just an integer, but check with the pthreads header files. The pthreads standard probably says what info is shared between threads in a process and what is not shared. An alternative is just to collect all the info and not make it explicit what information is shared and what is not, ie the list of threads for a process could just be another list of process info structures. That way you don't need to work out what is shared and what is not.
>> ie the list of threads for a process >> could just be another list of process info structures. THAT'S A HUGE WORK because this means (re)writing A LOT OF CODE (i guess about 7 functions * 7 archs => a list of 7 structures per TID ~2Ko), which is pointless if TID-info are very thin compared to PID-info. btw, you're complaining about TID != PID in nptl, so a list of threads is not a list of process. noticed that in my first proposal, there's a PID member refering to the leader process.
Ok, sorry, I'm not asking for huge amounts of code re-write. (I don't know the code base) How about the minimal/KISS approach as you suggested where the TID info is kept minimal to start with and extended if people find they really need extra per-thread info. I'd suggest just add the info that gnome-system-monitor reports, ie: tid, nice, (priority?), status, cpu% I don't know how cpu% is worked out, if that depends on lots of timeing stuff then as you said that needs more code, in which case maybe don't add that. The (s|u|r)time isn't a priority in itself I would say (gnome-system-monitor does not report these statistics).
*** Bug 303351 has been marked as a duplicate of this bug. ***
Benoît, wouldn't it be easier to disable the "show threads" button when running under a 2.6 kernel?
It's not that easy : i don't have NPTL on my ppc (running Debian SID kernel 2.6.11). AFAIK, you nead a compiler with TLS on your arch to get NPTL. The thread view is really buggy : - with NPTL, it doesn't show anything as libgtop is not aware of NPTL. - without NPTL, g-s-m thinks process B is a thread of process A if they have the same parent C, and same RSS (which often fails as RSS may change during the checks). Thread view = Off is useful for people without NPTL because it displays far less processes than top making g-s-m more readable.
Created attachment 57065 [details] [review] The patch Given that the thread view is really buggy, why not simply remove it and never show threads? The heuristic it currently uses is simply wrong as far as I can see, so given - it doesn't work with NPTL at all - it is slightly incorrect for LinuxThreads, which are rare systems these days - lord knows what it does on for non-Linux, why not remove it completely until it can be implemented correctly in libgtop? I am attaching a patch that simply deletes thread support.
-AC_CONFIG_HEADERS(config.h) +AM_CONFIG_HEADER(config.h) ?
Without that change I get: great-sage-equal-to-heaven:~/vertigo/procman% make cd . && aclocal-1.4 cd . && automake-1.4 --gnu Makefile configure.in: 8: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER' make: *** [Makefile.in] Error 1 But then, running autogen.sh again made that message go away. In any case, it's not part of the patch as such.
rerun the autogen.sh, procman now uses automake 1.9 thanks to jamesh.
Thanks for your patch :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgtop/issues/2.