pthread_setname_np undeclared


#1

A recent build of Juce results in this error:

In file included from ../source/modules/juce_core/juce_core.cpp:178:0: ../source/modules/juce_core/native/juce_posix_SharedCode.h: In static member function 'static void juce::Thread::setCurrentThreadName(const juce::String&)': ../source/modules/juce_core/native/juce_posix_SharedCode.h:878:57: error: 'pthread_setname_np' was not declared in this scope

This is Ubuntu 10.04, using gcc-4.6.

The build was fine ~2 months ago on the same system…
has something changed in the thread code?


#2

Seems to be this:

Is there a way to detect if pthread_setname_np is available?


#3

It might be possible by checking GLIBC and GLIBC_MINOR - what are those values on your distro?


#4

On my “good” system I have this:

#define __GLIBC__ 2 #define __GLIBC_MINOR__ 15

On the “bad” system it’s this:

#define __GLIBC__ 2 #define __GLIBC_MINOR__ 11

So as 2*1000+11 < 2012, the fix should work for old distros.

I’ll test it right away, thanks!


#5

If pthread_setname_np is not available, you can crib this function. Not sure under what conditions it is appropriate, though (although it seems to be Linux specific).

#include <sys/prctl.h>
void linux_thread_setname (char const* threadName)
{
    prctl (PR_SET_NAME, threadName, 0, 0, 0);
}

#6

That’s the same code that I originally used, but I replaced it with the pthread_setname call because IIRC someone reported that it didn’t work…


#7

You should definitely use pthread_setname_np but if that is unavailable for the platform, the prctl should be used as a fallback. If someone isn’t seeing the thread name, they likely either have a permission problem with their account or they forgot the proper flag in the ps command.


#8

np stands for “non portable”.
It’s not in the Posix standard. Yet, it’s supported with any decent (recent) GLibC on both MacOSX and Linux.
Older linux does not provide it, and the pctrl works on them because on those system a thread is a process (pctrl means process control).
So I think Vincent is right, if you intend to support older system, you need to provide a fallback, that, someday in the future, you’ll deprecate and remove.


#9

Can one of you describe a more complete fix?

I’m hung up on this with shared code (windows, osx, linux, etc) and not sure how to fix it for everyone.

Thanks!


#10

It’s fixed in the latest version… If something still doesn’t work, please explain what’s going wrong!