After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 134831 - add threads support to libgtop
add threads support to libgtop
Status: RESOLVED OBSOLETE
Product: libgtop
Classification: Core
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Benoît Dejean
System-monitor maintainers
: 303351 (view as bug list)
Depends on:
Blocks: 379533
 
 
Reported: 2004-02-19 13:12 UTC by Duncan
Modified: 2018-01-10 19:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The patch (6.06 KB, patch)
2006-01-09 21:28 UTC, Soren Sandmann Pedersen
committed Details | Review

Description Duncan 2004-02-19 13:13:16 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.
Comment 1 Benoît Dejean 2004-10-25 00:14:46 UTC
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.
Comment 2 Duncan 2004-10-26 10:18:09 UTC
> 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.
Comment 3 Benoît Dejean 2004-10-26 10:29:19 UTC
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 ?
Comment 4 Duncan 2004-10-26 16:56:06 UTC
They share all VM stuff and process name/args but have different nice, cpu %,
status and TID.
Comment 5 Benoît Dejean 2004-10-26 17:25:39 UTC
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 
Comment 6 Duncan 2004-10-26 18:17:07 UTC
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.
Comment 7 Benoît Dejean 2004-10-26 18:34:26 UTC
>> 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.
Comment 8 Duncan 2004-10-27 11:23:26 UTC
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).
Comment 9 Benoît Dejean 2005-05-07 10:46:10 UTC
*** Bug 303351 has been marked as a duplicate of this bug. ***
Comment 10 Bastien Nocera 2005-08-09 09:29:24 UTC
Benoît, wouldn't it be easier to disable the "show threads" button when running
under a 2.6 kernel?
Comment 11 Benoît Dejean 2005-08-09 10:14:39 UTC
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.
Comment 12 Soren Sandmann Pedersen 2006-01-09 21:28:31 UTC
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.
Comment 13 Benoît Dejean 2006-01-10 11:22:59 UTC
-AC_CONFIG_HEADERS(config.h)
+AM_CONFIG_HEADER(config.h)

 ?
Comment 14 Soren Sandmann Pedersen 2006-01-10 17:01:49 UTC
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.
Comment 15 Benoît Dejean 2006-01-10 18:06:14 UTC
rerun the autogen.sh, procman now uses automake 1.9 thanks to jamesh.
Comment 16 Benoît Dejean 2006-01-10 21:57:02 UTC
Thanks for your patch :)
Comment 17 GNOME Infrastructure Team 2018-01-10 19:41:31 UTC
-- 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.