3 ms·
This already exists. Windows had a janky way of naming threads before 10, but it has a supported API now. The problem is that svchost is a host that runs a th
by muststopmyths 7y ago
This already exists.
Windows had a janky way of naming threads before 10, but it has a supported API now.
The problem is that svchost is a host that runs a thread pool with various services being invoked as needed. You'd have to rename each thread every time you ran a function for a service.
That's probably more doable now with the supported API. The previous way involved raising an exception, so I can see why it wasn't done.
Seems like Windows has a more systemic testing problem though. We used to stress-test the crap out of various NT components back in the day. Don't know if the elimination of SDETs means there's no one doing that other than the NT perf team, which never did targeted stress.
- albertzeyer 7y agoFor reference, this was the old API: https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2015&redirectedfrom=MSDN https://docs.microsoft.com/en-us/visualstudio/debugger/how-t... This was well known, and many applications actually used that. Of course it was very ugly. I don't think it would have been a problem to also rename a given thread multiple times, but not sure.
- jgalar 7y agoIt's very ugly, but at least it doesn't seem to limit you to 15 characters like on Linux (prctl/pthread_set_name_np). That limit makes it pretty hard to provide meaningful identifiers in a non-trivial application.
- brucedawson 7y agoFunny thing, windbg apparently uses a fixed-size buffer to store the old-style thread names and it must use strncpy to copy them in because if your thread names are long enough then windbg displays the first ~15 characters and then shows garbage, because strncpy doesn't guarantee null-termination. Harmless I think, but sloppy.