Anonymous | Login | 2024-04-19 11:22 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0001292 | [1003.1(2016/18)/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 | |||||||
|
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_tdoes 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 |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |