On Tue Sep 16 18:52:19 2025 +0000, Elizabeth Figura wrote:
I have another pending patch that calls NetSetEvent from
NtSetEventBoostPriority but the condition under which NetSetEvent should be called is still unclear to me. Unconditionally, by my understanding.
Looking deeper at Xenia Canary SetBoostPriority() calls:
https://github.com/xenia-canary/xenia-canary/blob/canary_experimental/src/xe...:
`// SetEvent, but if there is a waiter we immediately transfer
execution to it`
This comment seems inline with @mzent assumptions that threads
awaiting the event are made immediately runnable. From a user space perspective, that's how NtSetEvent behaves too. If there's a difference it's in some slight nuances of how threads are prioritized by the scheduler, and that behaviour doesn't necessarily match between Windows and the host system, nor is it probably configurable.
I realize my commits should have been to a dedicated branch instead of master.
There's nothing wrong with using master on your local fork. It's not special.
Worse, I pulled commits by others to resolve Gitlab pipeline errors.
In hindsight that seems unnecessary and not advised?
It's not necessary in general.
Should I start over with a cleaner merge request once a solution ready?
No need for that; in fact it's better to avoid it, and keep this merge request in one place.
Latest pushed commit unconditionally calls NtSetEvent from NtSetEventBoostPriority.
It seems to me we should just add a quick test that it behaves like NtSetEvent(), and call NtSetEvent() from it if so.
This is the part that was unclear. By "quick test" I thought perhaps the suggestion was to query thread state info to somehow determine if behavior matched NtSetEvent.
Should a NtSetEventBoostPriority test be added to ./dlls/ntdll/tests/sync.c?
Xenia Canary still seems happy enough with this slightly more fleshed out implementation to the extent that the crash reported by the bug is still resolved. The game .iso still plays audio but with black screen instead of video which still seems to be a separate bug.