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.

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.

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.

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.

The "thread names" clause was a hyperlink to an article I wrote a few years listing all of the problems with thread naming on Windows. Microsoft took the suggestions seriously and basically landed all of the features and fixes that I requested, so now when I'm profiling or debugging Chrome the threads all have nice names.

I just kinda like trolling Microsoft for not using their own thread naming API very much.

https://randomascii.wordpress.com/2015/10/26/thread-naming-i...

I appreciate your efforts then. It's been a while since I was doing Windows development, but I remember staring at a bunch of hex values for thread IDs and despairing.

They can. Dawson specifically notes that there are no thread names here because he regularly harps on that subject e.g. https://randomascii.wordpress.com/2015/10/26/thread-naming-i... and https://randomascii.wordpress.com/2019/10/20/63-cores-blocke... ("plea for thread names" in the conclusion)

POSIX threads can be individually named. They inherit the name of their creator if you don't set one.

They can be named in Windows as well, and this author has made pleas for developers to do so.

The caveat being the developers who are careful enough to name their threads and implement good debug hooks aren't the ones you get called on to fix their code.

As an aside, POSIX/Linux thread names have a limit of 16 bytes, which means 15 characters plus NULL. Speaking from experience, this can and will bite you when you need the names the most, if e.g. they are long, have just one or a handful of common prefixes and their creation is not entirely under your control.

That would help, but I think the root problem here (of the debugging difficulty, not the actual perf problem) is the Windows approach of having lots of unrelated services running together in a single process (svchost)

Since Windows 10 1703/1709, if you have at least 4G of RAM or so, every service will run in its own svchost (for the most part there may be some exceptions). There's some registry key to tweak how much RAM is needed to trigger this.

Already possible in Windows [0].

[0]: https://docs.microsoft.com/en-us/windows/win32/api/processth...