Yes, I'm aware about these messages being printed and I wanted to fix them but never got to do it. I believe they are harmless though, and the priority gets set eventually.
I believe they are harmless though, and the priority gets set eventually.
Ah, I see the init_thread handler calls set_thread_priority again with the stored Windows priority. But there's this pesky
https://github.com/ValveSoftware/wine/blob/6e106909d6652c1eb6ad92d2df0eaee99ffc8296/server/thread.c#L843-L845
check in set_thread_priority which means that apply_thread_priority won't be called in this case, explaining why the priority wasn't being consistently being set in my applications. I removed it and the ps -T -O rtprio,pri,ni output for my application is now consistent. That check can just be removed, or changed if we really want to keep it. (And that setpriority failed message should stop being printed if unix_tid == -1.)
Looks like the above is addressed in bleeding-edge now, so closing. Thanks.
@ivyl the new patches removed the unix_tid == -1 check (so those unneeded messages get printed) and added back the above discussed check (there is a legitimate reason to call set_thread_priority with the an already applied priority, that is in DECL_HANDLER(init_thread), because previous calls from set_thread_info before handling that message will return an error (ESRCH) so you have to try again when there is a valid unix_tid from init_thread)
Actually, I somehow only just realized that this is reapplying the old patches in the OP, so I guess you probably have your reasons (bad performance with an application spamming the syscall?). I'll just fix it internally.
@layercak3 Yep - For some reason this had some unintended consequence and was causing audio static for some users (see https://github.com/ValveSoftware/Proton/issues/6653#issuecomment-2552165677) so we went ahead and reverted it.
Hm, I wonder if, it's because the application quickly and repeatedly sets the same thread priority which now goes through a syscall every time (I did see a different engine which likes to do this, though since this already involves going through wineserver, I feel like an application doing that would already be noticeably slow/high CPU), or now that the thread priorites are more correctly set the application is just setting some important threads low priority :/
The first hypothesis could be tested by improving the patch to keep a variable so the check can be done but only after the first thread priority application with a valid unix_tid has been attempted, and second by forcing the maxmimum nice to 0.
Sorry if this is a known issue. I often get a couple of
wine: setpriority (nice value) for pid -1 failed: 3(ESRCH because -1 is the initialized unix_tid in the wineserver's thread structure and invalid) messages from the wineserver with the thread priority patches (597aba9385cddd224216ed1f532fc1065a843bd2..e2003d21cf32c21c475291802d0af1fd385cb0d6, using bleeding-edge as well as backporting to vanilla). I read some debug logs and source code for a bit and it's because in these cases set_thread_info (tell wineserver the priority class of a thread among other things, sent in ntdll.NtSetInformationThread implementation. the wineserver patch calls setpriority on the threads unix_tid here) is received and processed by the wineserver very early before init_thread is received and processed (sent in the new thread at the very start of its execution, to tell wineserver its unix_tid). Sometimes you can get lucky with the scheduling and have more threads with priorities set than usual, especially when slowing things down with +relay,+server,+seh,+threadname,+thread.