tracy::GetThreadName(tracy::GetThreadHandle()) does not return the expected thread name on macOS

[dpelle]

My project builds on Linux, macOS and Android.

If I call tracy::SetThreadName("thread-name"), I then get the expected current thread name (i.e. "thread-name") on Linux or Android using:

tracy::GetThreadName(tracy::GetThreadHandle())

However, on macOS, it does not work as expected: instead of getting "thread-name" it returns something like "4439373" (I assume it's a thread ID). I see this when running tests in CI. I don't have a mac so I cannot reproduce the issue locally to provide more information unfortunately.

Is this a known limitation of Tracy on macOS or can we improve it?

I'm using Tracy v0.6.2 (git SHA1: ede90710e5433e5486a6e6d141ef1ba091e16536) which is not the latest.

[wolfpld]

Setting and getting thread names on OSX requires usage of pthread_id identifiers. Tracy instead uses kernel thread ids for thread identification.

tracy::GetThreadName will return a correct name if TRACY_ENABLE is defined, as the profiler performs its own bookkeeping of thread names.

[dpelle]

@wolfpld wrote:

tracy::GetThreadName will return a correct name if TRACY_ENABLE

Ah, I was hoping that I could use tracy::GetThreadName(…) as a portable way to get the thread name, even when TRACY_ENABLE is not defined. That works on Linux and Android at least.

So are we saying that on macOS, there is no way to get tracy::GetThreadName(…) working without TRACY_ENABLE? I'm not aware of a another portable c++ library to set/get the thread name (boost does not dot hat as far as I know), which is odd considering that it seems like a very generic thing to do.

[wolfpld]

You'd need to be able to retrieve pthread_id basing on the kernel thread id. How pthreads organize its identifiers is implementation defined and subject to change.

[dpelle]

What if I only care about the thread name of the current thread? (instead of the name of an arbitrary thread id)?

tracy::GetThreadName(…) requires a thread id as argument, but perhaps a function like tracy::GetCurrentThreadName() (without argument) could be made portable and work without -DTRACY_ENABLE?

[wolfpld]

This would be possible, but it's not required for profiler to work (i.e. would be very low priority).

[dpelle]

@wolfpld wrote:

This would be possible, but it's not required for profiler to work (i.e. would be very low priority).

Thanks. Good to know.

For your information, I wanted to get the current thread name, in a portable way, to show it when logging something, which is probably a common thing to do. E.g.:

ERROR: (current-thread-name) failed to open file foo.txt