Get "Native" thread id - feature request
Hello, is there a way how to get the thread id that system assigns to thread? I mean the id that is located in "thread_info->id". It would quite nice if boost could return this value, because for example if I want to set name of the thread on windows using function SetThreadName(), I need exactly that id. In my application I would have to add this "feature" directly to boost::thread.hpp, which is not very nice solution. I know that also GetThreadName(myThread->native_handle()) should work, but if I do it like this I always get a Windows error "The procedure entry point GetThreadId could not be located in the dynamic link library KERNEL32.dll". And I also guess, that this new "feature" wouldn't destroy the overall design of boost::thread architecture. To get the "real" thread id is in my opinion in general a useful thing.
On Thu, Nov 5, 2009 at 9:02 AM, Ondrej Sluciak < ondrej.sluciak@nt.tuwien.ac.at> wrote:
Hello, is there a way how to get the thread id that system assigns to thread? I mean the id that is located in "thread_info->id". It would quite nice if boost could return this value, because for example if I want to set name of the thread on windows using function SetThreadName(), I need exactly that id. In my application I would have to add this "feature" directly to boost::thread.hpp, which is not very nice solution. I know that also GetThreadName(myThread->native_handle()) should work, but if I do it like this I always get a Windows error "The procedure entry point GetThreadId could not be located in the dynamic link library KERNEL32.dll". And I also guess, that this new "feature" wouldn't destroy the overall design of boost::thread architecture. To get the "real" thread id is in my opinion in general a useful thing.
The reason is that GetThreadId only exists on 2003/Vista+. There is an undocumented way to do what you want, and it requires using NtQueryInformationThread which is undocumented. To use it you need to manually LoadLibrary / GetProcAddress. The output parameter of this function is another undocumented structure which contains the thread id. Nevertheless, look into it and I think you'll find at least something that works, even if it's ugly. That being said, I agree the thread id is important sometimes, if we have ability to get the handle there's no reason we shouldn't have the ability to get the id also.
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. Zachary Turner wrote:
On Thu, Nov 5, 2009 at 9:02 AM, Ondrej Sluciak
mailto:ondrej.sluciak@nt.tuwien.ac.at> wrote: Hello, is there a way how to get the thread id that system assigns to thread? I mean the id that is located in "thread_info->id". It would quite nice if boost could return this value, because for example if I want to set name of the thread on windows using function SetThreadName(), I need exactly that id. In my application I would have to add this "feature" directly to boost::thread.hpp, which is not very nice solution. I know that also GetThreadName(myThread->native_handle()) should work, but if I do it like this I always get a Windows error "The procedure entry point GetThreadId could not be located in the dynamic link library KERNEL32.dll". And I also guess, that this new "feature" wouldn't destroy the overall design of boost::thread architecture. To get the "real" thread id is in my opinion in general a useful thing.
The reason is that GetThreadId only exists on 2003/Vista+. There is an undocumented way to do what you want, and it requires using NtQueryInformationThread which is undocumented. To use it you need to manually LoadLibrary / GetProcAddress. The output parameter of this function is another undocumented structure which contains the thread id. Nevertheless, look into it and I think you'll find at least something that works, even if it's ugly.
That being said, I agree the thread id is important sometimes, if we have ability to get the handle there's no reason we shouldn't have the ability to get the id also. ------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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
On Thu, Nov 5, 2009 at 10:39 AM, Nigel Rantor
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.
Since you wouldn't spend too much energy arguing against it I guess there's no point in my response here :) But in any case, tons of libraries already expose things like this to get access to underlying os things. even thread already does it for the native_handle(). iostreams::file_descriptor does it for the native handle too. asio exposes native functionality to be able to use i/o completion ports on windows. Zach
Yes I found such ideas, that you can map the thread::id to whatever you want, but as you said, this can't do the job in some cases (like the one with setting the thread name for windows debugger). I don't know if you can call the ability of getting thread id a "hole" in the interface. It is quite reasonable that when I create a thread using boost, I want to know about the thread as much as possible, also by using boost..and knowing its system id isn't actually that much. I don't really see how this would break the portability of boost. I agree that there are maybe many people who are on the "fence", just like you, but there are many people who could appreciate this functionality and find it very useful. Nigel Rantor wrote:
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thu, Nov 5, 2009 at 10:30 AM, Ondrej Sluciak < ondrej.sluciak@nt.tuwien.ac.at> 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.
Most OSes don't even have the concept of thread names, so unfortunately there's no way to do that portably. I think your best bet is this: a) Use LoadLibrary and GetProcAddress to check if the function GetThreadId() exists. If it does, use it. If it doesn't, then: b) Use LoadLibrary and GetProcAddress to load NtQueryInformationThread. Search online (maybe in the ReactOS source code) to find the exact signature of the function and structure layout of the output parameter.
it requires using NtQueryInformationThread which is undocumented.
http://msdn.microsoft.com/en-us/library/ms684283(VS.85).aspx
On Thu, Nov 5, 2009 at 11:58 AM, Igor R
it requires using NtQueryInformationThread which is undocumented.
http://msdn.microsoft.com/en-us/library/ms684283(VS.85).aspx
Yes, but it's still undocumented. That's why the link above says [* NtQueryInformationThread* may be altered or unavailable in future versions of Windows. Applications should use the alternate functions listed in this topic.] Furthermore, it doesn't list the format of the output parameter. You can find it by searching around on google though, I don't have a link handy.
Ondrej Sluciak
To get the "real" thread id is in my opinion in general a useful thing.
It is, and you're not the only person to request it. I'll add it once 1.41 is out. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On Nov 5, 2009, at 7:02 AM, Ondrej Sluciak wrote:
Hello, is there a way how to get the thread id that system assigns to thread? I mean the id that is located in "thread_info->id". It would quite nice if boost could return this value, because for example if I want to set name of the thread on windows using function SetThreadName(), I need exactly that id. In my application I would have to add this "feature" directly to boost::thread.hpp, which is not very nice solution. I know that also GetThreadName(myThread->native_handle()) should work, but if I do it like this I always get a Windows error "The procedure entry point GetThreadId could not be located in the dynamic link library KERNEL32.dll". And I also guess, that this new "feature" wouldn't destroy the overall design of boost::thread architecture. To get the "real" thread id is in my opinion in general a useful thing.
I'm almost ashamed to post this, but maybe it helps you. Here's a really nasty hack that I came up with to get the Thread::id_t value of the thread id: Thread::id_t getId() { // This is awful. The Boost::thread implementation returns a thread_id class. // This is the only way to extract the actual value it carries, which is what a Thread::id_t // wants to be. In their Windows implementation, get_id() just returns an int, so we wouldn't // need this junk. std::stringstream ios; // This needs to be a pointer because on a *nix system, this_thread::get_id() // returns an object that defines operator<< to write the pthread_t to the stream, // and it's a pointer, so it gets formatted as hex and we can't change that by // inserting a dec manipulator. So when we read out of the stream, we need to // read into something for which a hex format makes sense. void *numericId; // If this is called before start(), we're hosed assert (bthread_); ios << bthread_->get_id(); ios >> numericId; // And, of course, static_cast can't be used to convert from void* to the integer type. return (Thread::id_t)numericId; } - Rush
On Nov 5, 2009, at 10:19 AM, Rush Manbert wrote:
On Nov 5, 2009, at 7:02 AM, Ondrej Sluciak wrote:
Hello, is there a way how to get the thread id that system assigns to thread? I mean the id that is located in "thread_info->id". It would quite nice if boost could return this value, because for example if I want to set name of the thread on windows using function SetThreadName(), I need exactly that id. In my application I would have to add this "feature" directly to boost::thread.hpp, which is not very nice solution. I know that also GetThreadName(myThread->native_handle()) should work, but if I do it like this I always get a Windows error "The procedure entry point GetThreadId could not be located in the dynamic link library KERNEL32.dll". And I also guess, that this new "feature" wouldn't destroy the overall design of boost::thread architecture. To get the "real" thread id is in my opinion in general a useful thing.
I'm almost ashamed to post this, but maybe it helps you.
Here's a really nasty hack that I came up with to get the Thread::id_t value of the thread id:
To clarify, Thread::id_t in the context of this code is typedefed as uint64_t, so what we're getting is just the integer value of the thread id.
Thread::id_t getId() { // This is awful. The Boost::thread implementation returns a thread_id class. // This is the only way to extract the actual value it carries, which is what a Thread::id_t // wants to be. In their Windows implementation, get_id() just returns an int, so we wouldn't // need this junk. std::stringstream ios; // This needs to be a pointer because on a *nix system, this_thread::get_id() // returns an object that defines operator<< to write the pthread_t to the stream, // and it's a pointer, so it gets formatted as hex and we can't change that by // inserting a dec manipulator. So when we read out of the stream, we need to // read into something for which a hex format makes sense. void *numericId;
// If this is called before start(), we're hosed assert (bthread_);
ios << bthread_->get_id(); ios >> numericId; // And, of course, static_cast can't be used to convert from void* to the integer type. return (Thread::id_t)numericId; }
- Rush_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (6)
-
Anthony Williams
-
Igor R
-
Nigel Rantor
-
Ondrej Sluciak
-
Rush Manbert
-
Zachary Turner