On Tue Jul 22 22:23:54 2025 +0000, Matteo Bruni wrote:
That was [https://gitlab.winehq.org/wine/wine/-/merge_requests/7797/diffs?diff_id=1701...] / [https://gitlab.winehq.org/wine/wine/-/merge_requests/7797/diffs?diff_id=1701...], for reference.
Sorry, which one (the link covers discussion for different topics, can't easily deduce where exactly it points to). Some guesses:
After the async has been changed to one of the "signaled" state, it's probably not supposed to go back to a state where it's not signaled. Mapping this to your state machine it's not a valid state transition as it wasn't done anywhere
I think of course async should not go back to 'unsignaled' state ever. But it should be going to signaled only once IOSB is delivered to client (AFAIU that is currently the case). And then it is the matter of wait_handle lifetime, not of unsignalling the async.
Then, I failed to find the place where sequential wait for handles is questioned, but I suspect the only possible matter their again deduces to wait_handle lifetime and making sure it is not closed prematurely? While should probably be created only on cancellation requests in the cases when it is not exist yet.