On Mon May 11 11:11:39 2026 +0000, Giovanni Mascellani wrote:
Which test is that? I see there is "multiple pending EnqueueResourceReady", but that does a different thing than that I had in mind. My idea was: * enqueue a `ResourceReady`; * enqueue a `ResourceReady` again; * execute `SignalEventOnResourceReady()`: it should signal immediately; * execute `SignalEventOnResourceReady()` again: does it signal immediately again? * execute `SignalEventOnResourceReady()` once again: does it signal immediately again? If only the first `SignalEventOnResourceReady()` signals immediately, then the `ResourceReady` behaves as an auto-resetting event; if the second `SignalEventOnResourceReady()` signals immediately but the third doesn't, then it behaves as a semaphore; it the third `SignalEventOnResourceReady()` signals immediately too, then it behaves as a manually-resetting event. Do we have a test that checks this? Ah, I see. I thought you meant this since you compared it to `ResourceRelease`, which requires all currently pending releases to run before it signals final release.
In the `EnqueueResourceReady / SignalEventOnResourceReady` test, two events both fire after one `ResourceReady`, although it calls SignalEventOnResourceReady on them before it calls EnqueueResourceReady. For now, I've removed "multiple pending EnqueueResourceReady" and added a test that does what you describe. There's also a `Reset` method that clears ready status, so the manual-reset nature is communicated quite explicitly I believe. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9777#note_139425