0001292: Add pthread_setname, pthread_getname

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
2020-11-05 21:30	joelsherrill	Issue Monitored: joelsherrill

Relationships

Aardvark Mark IV