Re:O(n^2), again, now in Windows Management Instrumentation
by albertzeyer on Monday December 09, 2019 @11:58AM
(#21744180)
For reference, this was the old API:
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.
Re:O(n^2), again, now in Windows Management Instrumentation
by jgalar on Monday December 09, 2019 @04:09PM
(#21746610)
It'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.
Re:O(n^2), again, now in Windows Management Instrumentation
by brucedawson on Monday December 09, 2019 @06:38PM
(#21747920)
Funny 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.
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.