Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001292 [1003.1(2016)/Issue7+TC2] Base Definitions and Headers Comment Enhancement Request 2019-09-27 19:37 2019-10-14 16:03
Reporter joelsherrill View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Joel Sherrill
Organization RTEMS.org
User Reference
Section pthread.h
Page Number NA - addition request
Line Number NA - addition request
Interp Status ---
Final Accepted Text see Note: 0004617
Summary 0001292: Add pthread_setname, pthread_getname
Description At least FreeBSD, Linux, RTEMS, QNX, and MKS currently provide pthread_setname_np() and pthread_getname_np() with this signature.

#include <pthread.h>

int pthread_setname_np(pthread_t thread, const char *name);
int pthread_getname_np(pthread_t thread, char *name, size_t len);

NOTE: QNX has int instead of size_t for the len parameter of pthread_getname_np().

AFAIK no implementation adds thread name as a pthread attribute
Desired Action This is a request to have these methods added to the base set of pthread methods.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0004573)
Konrad_Schwarz (reporter)
2019-09-30 08:49

I think the main rationale for excluding pthread names in Posix is that debugging (the prime consumer of such information) is out of scope.
(0004575)
wlerch (reporter)
2019-09-30 13:59

Debugging, as such, is out of scope, but building executables that enable debugging (c99 -g) doesn't seem to be. I would argue that setting thread names from code is on the same side of that line as the -g option.
(0004577)
shware_systems (reporter)
2019-09-30 16:55

Personally, I don't see that thread state for all threads need to be bloated with reserving space for this pointer, as the desired action implies. A sprintf(s, "Thread Id: %ju-%ju", (uintmax_t) getpid(), (uintmax_t) pthread_self()) does the job also, generically, for debugging or monitoring display, and individual applications desiring a non-generic display string can use a TLS slot for the purpose, using whatever key name they want.
(0004578)
wlerch (reporter)
2019-09-30 17:23

Individual applications defining their own private TLS slots for this is not quite as useful as a system-wide mechanism known to libraries and debugging tools.

If you're worried about bloat, the function could be required to exist but allowed to return ENOSYS.
(0004579)
GarrettWollman (reporter)
2019-09-30 17:24

The operating systems that support this functionality report thread status and thread names through other standard tools such as ps. Applications find it useful to be able to report thread information in this manner, and the interface as specified is clearly widely accepted in implementations that do not share a common lineage.

(Obviously, some implementations would not be able to provide this information to external processes, but that does not limit its utility as a portable interface for applications to supply this information.)

I believe it is not supported as a thread attribute because the common usage in applications is to start multiple threads with the same attributes; they can use thread names to provide more information about what the threads are doing after they are created. pthread_setname_np() was added as the threaded equivalent of setproctitle() which is commonly used for this purpose in single-threaded applications.
(0004580)
GarrettWollman (reporter)
2019-09-30 17:31

If we were to add this interface (which would require one of TOG, IEEE, or ISO to sponsor it), the specification would have to be clear about the expected lifetime of the name argument to pthread_setname() -- some implementations pass the name to a system call, which takes a copy, whereas other implementations will store it in a data structure within the process.
(0004581)
GarrettWollman (reporter)
2019-09-30 17:33

Also, for those who are looking, FreeBSD spells this interface pthread_set_name_np() (with an underscore).
(0004582)
Konrad_Schwarz (reporter)
2019-10-01 07:24

Note: 0004577 is not conforming:
pthread_t
does not need to be a scalar.

I think the real point is that, for named threads to be useful,
you need to be able to enumerate them. This conflicts with
with an n:m thread model, because the data structure (e.g., a linked list)
resides in user space in that model, so can be corrupted, and so cannot
be trusted by outside tools.
(0004583)
joerg (reporter)
2019-10-01 09:24
edited on: 2019-10-01 09:27

Re: Note: 0004582

Well, pthread_t may be a pointer and since the related data is in shared memory, I expect these pointers to be unique inside a process.

(0004584)
Konrad_Schwarz (reporter)
2019-10-01 10:35

Re: Note: 0004583: pointers are scalars, according to C.

I think HP-UX was the cannonical example of a pthreads
implementation where a pthread_t was a structure.
(0004585)
shware_systems (reporter)
2019-10-01 15:49

Re:4582
Yes, it's not viable for all circumstances permitted, but will work on most implementations. I was thinking pthread_t was an integer or pointer, as most use now, so pthread_self() would return something that fits in uintmax_t. Perhaps an interface such as size_t pthread_index(bool proconly) is needed; that would provide such an enumeration value for all executing threads or, if proconly true, just for the current process.
(0004588)
alanc (reporter)
2019-10-01 22:03

Oracle Solaris 11.3.16 and later also have:
extern int pthread_setname_np(pthread_t, const char *);
extern int pthread_getname_np(pthread_t, char *, size_t);

as documented in:
https://docs.oracle.com/cd/E88353_01/html/E37843/pthread-setname-np-3c.html [^]
(0004590)
enh (reporter)
2019-10-02 00:13

Android has had

  int pthread_setname_np(pthread_t __pthread, const char* __name);

since the beginning, and

  int pthread_getname_np(pthread_t __pthread, char* __buf, size_t __n);

since API level 26 (aka 8.0 aka "Oreo").

the former has the same ERANGE behavior as glibc, which is annoying but we felt it better not to be surprisingly different.
(0004617)
eblake (manager)
2019-10-14 16:01

This was discussed on the 2019-10-14 call. The sentiment was that within the
confines of a single process, thread local storage already exists as a portable
way to get the same effect. Outside of a single process, accessing the ID or
name of a thread (or for that matter, any other details), is already an
implementation-specific extension; we would feel more comfortable first
standardizing a way for the ps utility to output thread-specific information
before adding a pthread_setname() that would affect ps output in a way that
makes sense, but altering ps is a much more complex task. Thus, at this time,
this proposal is being rejected, although implementations should still feel
free to provide it as an extension.

We also note that some implementations limit the string to 16 bytes, some to
32-bytes, and some to 2048 bytes. Some implementations truncate longer
strings, some error on overlong strings, while others do not specify what
happens with longer strings. And, since truncation could result in a split on
a non-character boundary, we are even less inclined to accept this function
without a clear specification on what a function to add a thread name should
do if the given string is too long.

- Issue History
Date Modified Username Field Change
2019-09-27 19:37 joelsherrill New Issue
2019-09-27 19:37 joelsherrill Name => Joel Sherrill
2019-09-27 19:37 joelsherrill Organization => RTEMS.org
2019-09-27 19:37 joelsherrill Section => pthread.h
2019-09-27 19:37 joelsherrill Page Number => NA - addition request
2019-09-27 19:37 joelsherrill Line Number => NA - addition request
2019-09-30 08:49 Konrad_Schwarz Note Added: 0004573
2019-09-30 13:59 wlerch Note Added: 0004575
2019-09-30 16:55 shware_systems Note Added: 0004577
2019-09-30 17:23 wlerch Note Added: 0004578
2019-09-30 17:24 GarrettWollman Note Added: 0004579
2019-09-30 17:31 GarrettWollman Note Added: 0004580
2019-09-30 17:33 GarrettWollman Note Added: 0004581
2019-10-01 07:24 Konrad_Schwarz Note Added: 0004582
2019-10-01 09:24 joerg Note Added: 0004583
2019-10-01 09:24 joerg Note Edited: 0004583
2019-10-01 09:24 joerg Note Edited: 0004583
2019-10-01 09:27 joerg Note Edited: 0004583
2019-10-01 09:27 joerg Note Edited: 0004583
2019-10-01 10:35 Konrad_Schwarz Note Added: 0004584
2019-10-01 15:49 shware_systems Note Added: 0004585
2019-10-01 22:03 alanc Note Added: 0004588
2019-10-02 00:13 enh Note Added: 0004590
2019-10-14 16:01 eblake Note Added: 0004617
2019-10-14 16:03 eblake Interp Status => ---
2019-10-14 16:03 eblake Final Accepted Text => see Note: 0004617
2019-10-14 16:03 eblake Status New => Closed
2019-10-14 16:03 eblake Resolution Open => Rejected


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker