Blank thread names on Windows
BullyWiiPlaza opened this issue · comments
On Linux threads are assigned names in the form of random (?) hex codes by default but on Windows their names stay blank. Is there any particular reason for this or maybe the behavior of loguru can be adjusted to be the same for both OS'es (e.g. that Windows also receives automatic thread naming)? I know that you can use loguru to set the thread name via loguru::set_thread_name but I would rather have the automatic way of assigning thread names on Windows as well for consistency reasons.
I don't use Windows, so I can't really help here.
I agree that blank names is less than optimal. If the names are blank we should probably default to a hex of their ID:s instead.
Alright. I'm offering my help to test on Windows. Just let me know your concrete suggestion for an implementation or I can try to roll my own based on your last comment at some point and send a pull request.
Thanks!
Win32 has a proper API for getting/setting thread names, but it doesn't look like Loguru is using it. If I recall correctly, the API is so horrible that it just not worth the hassle (feel free to investigate further).
So instead, loguru::set_thread_name and loguru::get_thread_name writes/reads to a thread-local variable (which is accessed via get_thread_name_win32 here, a function that should probably be called get_thread_local_thread_name_buffer or similar to be less confusing).
This means that if you spawn a thread and call loguru::set_thread_name, then loguru::get_thread_name should work as you would expect. If you don't call loguru::set_thread_name then that thread local string will remain empty, which explain the empty strings you are getting. So loguru::get_thread_name should detect that the thread name is empty (unset), and then instead return the thread id as some hex string. We do that fallback on the other platforms, so it makes sense to add it for windows too.
See https://github.com/emilk/loguru/blob/master/loguru.cpp#L1052 for details!
Well, that was quite easy:
#158