Date: Wed, 2 May 2018 05:03:25 -0400 From: Daniel Eischen <deischen@freebsd.org> To: Julian Elischer <julian@freebsd.org> Cc: Konstantin Belousov <kib@freebsd.org>, Manuel St?hn <freebsdnewbie@freenet.de>, freebsd-hackers@freebsd.org Subject: Re: Getting pthread names Message-ID: <A95FCDF4-CEC0-41CF-B60E-9FB14DFD3953@freebsd.org> In-Reply-To: <44e3f0c6-0397-404b-3fb9-a67e7f592024@freebsd.org> References: <20180430111434.GA18085@freebsd-t450.fritz.box> <20180430135711.GT6887@kib.kiev.ua> <44e3f0c6-0397-404b-3fb9-a67e7f592024@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 1, 2018, at 10:38 PM, Julian Elischer <julian@freebsd.org> wrote: >=20 >> 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, >>>=20 >>> 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@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >>=20 > and ps in the kernel debugger shows it as well from memory >=20 > check top and ps in "show thread" mode.... at one stage I remember writing= code to show thread names >=20 > but I can't remember what programs it went into.. (around 2001), >=20 >=20 > I suspect that you are expected to remember your own name. the name writin= g is so other processes can get that information. I think I toyed with idea of adding pthread_set_name_np() back in the old li= bc_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 o= r code out of your control. Maybe not a common use case, though. The set n= ame function is void return, so you can't even get the name to see if the se= tter actually worked. I think the libc_r version just did a strdup() of sor= ts, so it could be as long as necessary (bug or feature?). The current lim= it seems to be MAXCOMLEN, which is 19, and I think just silently fails if mo= re than that. -- DE=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A95FCDF4-CEC0-41CF-B60E-9FB14DFD3953>