Getting pthread names

[Daniel Eischen]

> On May 1, 2018, at 10:38 PM, Julian Elischer <julian at freebsd.org> wrote:
> 
>> On 30/4/18 9:57 pm, Konstantin Belousov wrote:
>>> On Mon, Apr 30, 2018 at 01:14:34PM +0200, Manuel St?hn wrote:
>>> Hi,
>>> 
>>> for setting a name for pthreads i found pthread_set_name_np(3), but for
>>> retrieving the name i found nothing. Is there any api like
>>> pthread_getname_np for FreeBSD? Or is there another way to retrieve the
>>> threads name within an application?
>> Not like pthread_getname_np(), but still something.  You can use
>> (binary) sysctl kern.proc.pid.<pid> to get struct kinfo_proc for all
>> threads.  In the structure, the ki_tdname() member contains the thread
>> name as set by pthread_set_name_np(3).
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>> 
> and ps in the kernel debugger shows it as well from memory
> 
> check top and ps in "show thread" mode.... at one stage I remember writing code to show thread names
> 
> but I can't remember what programs it went into..  (around 2001),
> 
> 
> I suspect that you are expected to remember your own name. the name writing is so other processes can get that information.

I think I toyed with idea of adding pthread_set_name_np() back in the old libc_r days.  I'm not sure why I didn't?

The problem with remembering to
what you set each thread's name, is that the names may be set by libraries or code out of your control.  Maybe not a common use case, though.  The set name function is void return, so you can't even get the name to see if the setter actually worked.  I think the libc_r version just did a strdup() of sorts, so it could be as long as necessary (bug or feature?).  The  current limit seems to be MAXCOMLEN, which is 19, and I think just silently fails if more than that.

--
DE