[PATCH] Linux implementation for set_native_thread_name()

[David Holmes]

On 26/07/2012 10:18 PM, Roman Kennke wrote:
> Am Donnerstag, den 26.07.2012, 22:00 +1000 schrieb David Holmes:
>> Roman,
>>
>> On 25/07/2012 7:10 AM, Roman Kennke wrote:
>>>> I think it looks fine.
>>>
>>> Great! I posted an updated webrev for this (replaced snprint with
>>> jio_snprintf):
>>
>> You are assuming that these non-posix pthread extensions will always
>> exist. Do we know that is true for all Linux's - including potentially
>> custom distributions on embedded systems? I think we need dynamic lookup
>> of the function, as done elsewhere, to verify that it exists.
>
> Do you mean at runtime, using dlopen or such? Or at compile time, using
> #ifdefs ?

Runtime using dlsym, the same way we look for the "optional" POSIX 
functions like clock_gettime. The support for this in linux/libc is very 
recent (in OS terms):

http://sourceware.org/ml/libc-help/2010-03/msg00015.html

You might also follow the BSD version and add a Java prefix:

   if (name != NULL) {
     // Add a "Java: " prefix to the name
     char buf[MAXTHREADNAMESIZE];
     snprintf(buf, sizeof(buf), "Java: %s", name);
     pthread_setname_np(buf);
   }

though that concerns me if MAXTHREADNAMESIZE is only 16!

Can you tell me where this max name size is coming from? I can google 
different docs for pthread_setname_np and some say it internally limits 
the name length, while others say if the name is too long it gives an 
E2BIG error. The source code at

http://sourceware.org/ml/libc-help/2010-03/msg00015.html

does not set a specific limit on the length but will return a error if 
it can't write the full name. In contrast the cygwin version:

http://www.mail-archive.com/cygwin-patches@cygwin.com/msg05387.html

sets a limit of 16(actually 15 characters plus NUL) and returns ERANGE.

This is why we try to stay away from the ill-defined _np functions.

David
-----

>
>>> http://cr.openjdk.java.net/~rkennke/linux_threadname/webrev.01/
>>
>> This also has the distribute_processes etc changes, which should be
>> handled seperately.
>
> Uff. I messed up something there. Please find the real webrev here:
>
> http://cr.openjdk.java.net/~rkennke/linux_threadname/webrev.02/
>
>
>>>> Do you have a bug number for this?
>>>
>>> No. (I don't have access to bugster anymore).
>>
>> Bugster is nearly dead - long live Jira :)
>
> Wow, cool!
>
>>   But for now someone will need
>> to create a bug for this ... though it may already exist from when this
>> function was added.
>>
>>>>     Also, how do we verify the result?
>>>
>>> I verified it using htop and by inspecting /proc/$PID/task/$TID/stat.
>>> Unfortuntately, I couldn't get top or ps to show the thread name, but
>>> maybe I'm just stupid (and I did not try very hard).
>>
>> gdb? Not sure how this shows up on OSX. If the name doesn't appear in
>> anything useful then there's not much point implementing the method.
>
> Yes, gdb shows the thread name as well (dunno why I forgot about this
> most obvious use case).
>
>>> Also: which of the many repositories do I need to push this to?
>>
>> It would go into hsx/hotspot-rt forest, but you can't push it directly.
>> All hotspot changes must go via JPRT so you will need a sponsor.
>
> Ok. I think Keith said he can do this. :-)
>
> Thanks!
>
> Regards,
> Roman
>
>