0001292: Add pthread_setname, pthread_getname

ID	Project	Category	View Status	Date Submitted	Last Update

0001292	1003.1(2016/18)/Issue7+TC2	Base Definitions and Headers	public	2019-09-27 19:37	2019-10-14 16:03

Reporter	joelsherrill	Assigned To
Priority	normal	Severity	Comment	Type	Enhancement Request
Status	Closed	Resolution	Rejected

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 0001292: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.

Konrad_Schwarz 2019-09-30 08:49 reporter bugnote:0004573	I think the main rationale for excluding pthread names in Posix is that debugging (the prime consumer of such information) is out of scope.

wlerch 2019-09-30 13:59 reporter bugnote:0004575	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.

shware_systems 2019-09-30 16:55 reporter bugnote:0004577	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.

wlerch 2019-09-30 17:23 reporter bugnote:0004578	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.

GarrettWollman 2019-09-30 17:24 reporter bugnote:0004579	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.

GarrettWollman 2019-09-30 17:31 reporter bugnote:0004580	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.

GarrettWollman 2019-09-30 17:33 reporter bugnote:0004581	Also, for those who are looking, FreeBSD spells this interface pthread_set_name_np() (with an underscore).

Konrad_Schwarz 2019-10-01 07:24 reporter bugnote:0004582	0001292: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.

joerg 2019-10-01 09:24 reporter bugnote:0004583 Last edited: 2019-10-01 09:27	Re: 0001292: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.

Konrad_Schwarz 2019-10-01 10:35 reporter bugnote:0004584	Re: 0001292: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.

shware_systems 2019-10-01 15:49 reporter bugnote:0004585	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.

alanc 2019-10-01 22:03 reporter bugnote:0004588	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

enh 2019-10-02 00:13 reporter bugnote:0004590	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.

eblake 2019-10-14 16:01 manager bugnote:0004617	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.

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 0001292:0004617
2019-10-14 16:03	eblake	Status	New => Closed
2019-10-14 16:03	eblake	Resolution	Open => Rejected

View Issue Details

Activities

Issue History