Ondrej Sluciak wrote:
Thank you for your hints. Well, it isn't just question of SetThreadName function on Windows. The ability to get the real thread id is quite crucial when you want to debug or when you want to log also thread behaviour. On linux you are also interested in real pids. I mean it would be really great if you could also set thread names (and get thread names) directly using boost (and not using those undocumented windows functions), but I don't know if there is some general way how to do it on any OS, so I don't know if it would be "feasible" to put it in boost. On the other hand, getting only thread ids can be done on any OS (as far as I know). So at least this functionality would be nice to have in boost.
A question like this has come up before with respect to being able to identify threads. If you only want to name threads then you can use the thread::get_id() function. The thread::id value provides a comparison operator so that you can use it in, for example a std::mapthread::id,std::string to provide a mapping between boost ids and something more user-friendly. Yes, this doesn't necessarily fit very well with a debugger but for lots of applications this is enough, to be able associate a "name" with a thread. I understand why you want to be able to get to the "raw" id, and it would, in all probability, be a change that doesn't break anyone, but it does give people the temptation to break portability without thinking about other solutions that are open to them. I'm on the fence basically. I wouldn't suggest breaking a hole in the interface to let you peek at the OS id but I also wouldn't spend too much energy arguing against it. n