[Bug libc/11390] New: support for pthread_setname_np() / pthread_getname_np()

[Bug libc/11390] New: support for pthread_setname_np() / pthread_getname_np()

[johnstul at us dot ibm dot com]

Since 2.6.33, the Linux kernel now allows thread-siblings to rename task comm
values via the /proc/self/task/<tid>/comm value. Glibc could include support for
the  pthread_setname_np() / pthread_getname_np()interfaces to expose this feature.

An initial rough RFC patch for this support was sent the libc-help list, but got
no reply:
http://sourceware.org/ml/libc-help/2010-01/msg00018.html

-- 
           Summary: support for pthread_setname_np() / pthread_getname_np()
           Product: glibc
           Version: 2.10
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: johnstul at us dot ibm dot com
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11390

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11390] support for pthread_setname_np() / pthread_getname_np()

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2010-04-08 18:21 -------
How is this related to the PR_SET_PROCTITLE_AREA proposal (or a new syscall for
this, whatever will actually be accepted)?  Shouldn't that we the interfaces
changed?  The comm file seems limited.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=11390

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11390] support for pthread_setname_np() / pthread_getname_np()

[johnstul at us dot ibm dot com]

------- Additional Comments From johnstul at us dot ibm dot com  2010-04-09 01:12 -------
Its not related to PR_SET_PROCTITLE_AREA.

My understanding is PR_SET_PROCTITLE_AREA is per process, and is accessed via
proc/<pid>/cmdline. 

The /proc/self/task/<tid>/comm value is per thread and utilizes the taskstruct's
comm value. Its closer to the PR_SET_NAME prctl interface, only it allows thread
siblings to set each other's comm.

The initial motivation for this work was allow large java processes with
hundreds of threads to be able to name the threads, so external analysis could
make some sense of which thread what doing.

I'll admit the task->comm length is limiting, but the 1:1 mapping of what the
kernel often uses (as well as things like perf and ftrace output) makes it quite
useful.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=11390

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11390] support for pthread_setname_np() / pthread_getname_np()

[johnstul at us dot ibm dot com]

------- Additional Comments From johnstul at us dot ibm dot com  2010-04-09 01:28 -------
"make sense of which thread what doing."

Sorry, that should be "make sense of which thread was doing what."


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11390

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11390] support for pthread_setname_np() / pthread_getname_np()

[johnstul at us dot ibm dot com]

------- Additional Comments From johnstul at us dot ibm dot com  2010-04-09 02:18 -------
Created an attachment (id=4712)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4712&action=view)
Rough patch implementing pthread_get/setname_np() against current -git

Just for reference, here's the rough implementation I sent to the glibc-help
list.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11390

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11390] support for pthread_setname_np() / pthread_getname_np()

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2010-04-09 08:15 -------
I don't like the limitation but I added the code.  It's not really a good idea
to rely on the /proc filesystem.  This is why the code I committed uses prctl
when possible.  Perhaps if people find the interface useful pressure on the
kernel people is sufficient to enlarge the field.

I didn't use your code.  It contained many problems and unnecessary code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=11390

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11390] support for pthread_setname_np() / pthread_getname_np()

[johnstul at us dot ibm dot com]

------- Additional Comments From johnstul at us dot ibm dot com  2010-04-09 19:15 -------
(In reply to comment #5)
> I don't like the limitation but I added the code.  It's not really a good idea
> to rely on the /proc filesystem.  This is why the code I committed uses prctl
> when possible.  Perhaps if people find the interface useful pressure on the
> kernel people is sufficient to enlarge the field.
> 
> I didn't use your code.  It contained many problems and unnecessary code.

Thanks Ulrich!

By the way, I was looking at the git commit you made
86a4c67fb91b82c7b47c115b88ab01b1a696f10f and noticed there is a small bug.

In pthread_getname_np, you are using PR_SET_NAME not PR_GET_NAME with the prctrl.


thanks again
-john

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11390

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.