On 9/26/22 17:24, Brendan Shanks (@bshanks) wrote:
These are going to get cut off on Linux, which rather unfortunately has a hard limit of 15 characters. Should we try to make these shorter? I didn't notice earlier, but the same applies to fa8e36fafa and 3f0166fa89.
It is a very short limit on Linux, but the full names do show up in the `+threadname` debug channel and in `winedbg`.
I think the best we can do is try to ensure the 15 characters include at least `wine` and which DLL the thread comes from, and also that it's uniquely identifiable (for searching).
`wined3d_budget`, `wined3d_set_win`, or `wine_wininet_co` at least make it clear where to start looking. I'm not sure if we could really shorten those either, using CamelCase would help a bit but doesn't match the project style.
For fa8e36fafa though, `wine_threadpool` alone takes up the 15 chars, maybe I should have used `wine_tp` so there will be some unique part in the 15 chars.
Also since no Windows software is written with limited-length thread names in mind (since at least VC6), I suspect anyone looking at 15 character names will need to have a `+threadname` log or `winedbg` to cross-reference with anyway.
Sure, makes sense. I do at least think it's a good idea to try to make the thread names unique and readable with host tools; I've found that to be very useful with multiple such tools (`top -H`, `pidstat -t` and gpuvis all come to mind).
Perhaps we could try to introduce support for longer task names in the Linux kernel? I guess it'd need a new API, though, since changing the limit would break ABI :-/