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

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
[email protected] T/L 678-3059

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

@@ -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);	

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
[email protected] T/L 678-3059

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

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
[email protected] T/L 678-3059

In article <26210000.998324773@baldur>,

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.

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
[email protected] T/L 678-3059

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   `------------------------

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

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
[email protected] T/L 678-3059