[PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status

[PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status

[Dave McCracken]

It would be useful in many contexts to be able to see the thread group id. 
This would make it easier to identify tasks that are part of a 
multi-threaded process, at least for those that are using pthreads.  This 
patch adds a TGid field to the status file.  This will not break ps, since 
ps skips any field in status that it doesn't understand.

Patch is below.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059

==========================

--- linux-2.4.9/./fs/proc/array.c	Thu Jul 26 15:42:56 2001
+++ linux-2.4.9-tgid/./fs/proc/array.c	Mon Aug 20 10:05:18 2001
@@ -153,11 +153,12 @@
 		"State:\t%s\n"
 		"Pid:\t%d\n"
 		"PPid:\t%d\n"
+		"TGid:\t%d\n"
 		"TracerPid:\t%d\n"
 		"Uid:\t%d\t%d\t%d\t%d\n"
 		"Gid:\t%d\t%d\t%d\t%d\n",
 		get_task_state(p),
-		p->pid, p->pid ? p->p_opptr->pid : 0, 0,
+		p->pid, p->pid ? p->p_opptr->pid : 0, p->tgid, 0,
 		p->uid, p->euid, p->suid, p->fsuid,
 		p->gid, p->egid, p->sgid, p->fsgid);
 	read_unlock(&tasklist_lock);	

Re: [PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status

[Alan Cox]

> This would make it easier to identify tasks that are part of a 
> multi-threaded process, at least for those that are using pthreads.  This 
> patch adds a TGid field to the status file.  This will not break ps, since 
> ps skips any field in status that it doesn't understand.

I didnt think anyone was using the broken tgid stuff ?

Re: [PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status

[Dave McCracken]

--On Monday, August 20, 2001 17:19:13 +0100 Alan Cox 
<alan@lxorguk.ukuu.org.uk> wrote:

> I didnt think anyone was using the broken tgid stuff ?

I was under the impression that the current LinuxThread library does use 
CLONE_THREAD, and I know of at least one project under way that's also 
using it (the NGPT pthread library).  The getpid() system call already 
returns tgid instead of pid.  I'm also looking into what's involved in 
making tgid more robust.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmc@austin.ibm.com                                      T/L   678-3059

Re: [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status

[george anzinger]

Dave McCracken wrote:
> 
> --On Monday, August 20, 2001 17:19:13 +0100 Alan Cox
> <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > I didnt think anyone was using the broken tgid stuff ?
> 
> I was under the impression that the current LinuxThread library does use
> CLONE_THREAD, and I know of at least one project under way that's also
> using it (the NGPT pthread library).  The getpid() system call already
> returns tgid instead of pid.  I'm also looking into what's involved in
> making tgid more robust.
> 
> Dave McCracken

Are you possibly also looking into allocating a small data structure to
the thread group?  A place to keep thread group signal info, perhaps?

George

Re: [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status

[Dave McCracken]

--On Monday, August 20, 2001 11:50:37 -0700 george anzinger 
<george@mvista.com> wrote:

> Are you possibly also looking into allocating a small data structure to
> the thread group?  A place to keep thread group signal info, perhaps?

No, not specifically.  A mechanism already exists to share info between 
cooperating tasks, where there's a common structure pointed to by each task 
(ie mm_struct, signal_struct, files_struct, fs_struct, etc).  I think we 
can use this mechanism for any info a group of tasks needs to share.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmc@austin.ibm.com                                      T/L   678-3059

Re: [PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status

[Miquel van Smoorenburg]

In article <26210000.998324773@baldur>,
Dave McCracken  <dmc@austin.ibm.com> wrote:
>
>--On Monday, August 20, 2001 17:19:13 +0100 Alan Cox 
><alan@lxorguk.ukuu.org.uk> wrote:
>
>> I didnt think anyone was using the broken tgid stuff ?
>
>I was under the impression that the current LinuxThread library does use 
>CLONE_THREAD, and I know of at least one project under way that's also 
>using it (the NGPT pthread library).  The getpid() system call already 
>returns tgid instead of pid.  I'm also looking into what's involved in 
>making tgid more robust.

Hmm, I've always been a bit curious about this .. I don't think getpid()
should return tgid instead of pid. It looks broken to me. Thread groups
are a good idea, but they should act more like process groups do.
Switching pid and tgid is something that the LinuxThreads library
should probably do, but not the kernel. IMHO.

If one really wants CLONE_PID to work, fix CLONE_PID.

Mike.

Re: [PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status

[Ulrich Drepper]

miquels@cistron-office.nl (Miquel van Smoorenburg) writes:

> Switching pid and tgid is something that the LinuxThreads library
> should probably do, but not the kernel. IMHO.

Not possible until the signal handling in the kernel is thread group
aware.  Grab Linus' patch from ten months os so ago, fix it, and get
it into the kernel.  Then we can rewrite the signal handling and make
getpid behave correctly.

Having said this, since this is a known deficiency no program should
use getpid for some critical unless it's absolutely necessary.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [PATCH] 2.4.9 Make thread group id visible in /proc/<pid>/status

[Dave McCracken]

--On Monday, August 20, 2001 19:09:16 +0000 Miquel van Smoorenburg 
<miquels@cistron-office.nl> wrote:

> Hmm, I've always been a bit curious about this .. I don't think getpid()
> should return tgid instead of pid. It looks broken to me. Thread groups
> are a good idea, but they should act more like process groups do.
> Switching pid and tgid is something that the LinuxThreads library
> should probably do, but not the kernel. IMHO.
>
> If one really wants CLONE_PID to work, fix CLONE_PID.

I wasn't on the list when getpid() was changed to return tgid.  I don't 
have a strong feeling about it, though it does make pthread semantics 
simpler.

CLONE_PID really isn't the semantic we want, though.  That would make all 
tasks in the process have the same pid, and no way to address a specific 
task.  We'd have to introduce something like a task id or a thread id. 
Having tgid and pid gives us the tools we need, and minimizes the 
compatibility issues.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059

Re: [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status

[george anzinger]

Dave McCracken wrote:
> 
> --On Monday, August 20, 2001 11:50:37 -0700 george anzinger
> <george@mvista.com> wrote:
> 
> > Are you possibly also looking into allocating a small data structure to
> > the thread group?  A place to keep thread group signal info, perhaps?
> 
> No, not specifically.  A mechanism already exists to share info between
> cooperating tasks, where there's a common structure pointed to by each task
> (ie mm_struct, signal_struct, files_struct, fs_struct, etc).  I think we
> can use this mechanism for any info a group of tasks needs to share.
> 
But this (signal_struct) does not share the signals, just the
infrastructure.  I believe the thread standard defines some signals that
are to be delivered to a "thread leader" regardless of what actually
caused the signal.  Thus for these signals a separate mask & signal
queue seems in order.  I suppose one could use the union of all the
thread masks or some such, but this seems like a lot of overhead.  Also
need to introduce the concept of a "thread leader" (the thread that this
group of signals is to be delivered to) and what happens when the
"thread leader" exits (how a new "thread leader" is chosen).  I suspect
that the standard addresses all this, but I don't yet have access to the
standard.

Then, again, I could be suffering from too much coffee :)

George

Re: [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status

[Dave McCracken]

--On Monday, August 20, 2001 12:52:05 -0700 george anzinger 
<george@mvista.com> wrote:

> But this (signal_struct) does not share the signals, just the
> infrastructure.  I believe the thread standard defines some signals that
> are to be delivered to a "thread leader" regardless of what actually
> caused the signal.  Thus for these signals a separate mask & signal
> queue seems in order.  I suppose one could use the union of all the
> thread masks or some such, but this seems like a lot of overhead.  Also
> need to introduce the concept of a "thread leader" (the thread that this
> group of signals is to be delivered to) and what happens when the
> "thread leader" exits (how a new "thread leader" is chosen).  I suspect
> that the standard addresses all this, but I don't yet have access to the
> standard.

Oh, I agree that a need exists for this kind of semantic.  I was just 
saying that we do have a place to add the info necessary for it.  We could 
add it to signal_struct, or we could create another structure that's shared 
in a similar fashion.

We can easily add the concept of 'thread group leader'.  We already have 
the task that has 'tgid == pid', ie the first task that called clone() with 
CLONE_THREAD.  It would be simple enough to expand on that.

Actually the signal semantics you want in the kernel aren't necessarily 
just an implementation of the POSIX process-wide semantic.  What you want 
is to assume there's a library that's implementing the semantic, and funnel 
the signals to it.  Directing them all to a single task (thread group 
leader, for example) is one good way to do it.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059