On Mon May 5 14:41:33 2025 +0000, Matteo Bruni wrote:
Well, it's not really about the `signaled` meaning, but about
resetting it arbitrarily just so that the cancelling thread can wait on it.
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. This is probably a fair concern (with the caveat that nobody here seems to have a clear idea of all the intricacies involved :sweat_smile:). I don't know for sure that e.g. creating a separate event would be more proper. I think I remember starting with that, then switching to just creating a handle for the async if it's not around already. I don't recall anymore but it doesn't feel like I encountered hard-blockers with that, it just seemed simpler to do it like I ended up doing.
It seems to me that before we can actually implement proper async cancellation, we will need to clarify what exactly is the semantics of the wait that follows the cancellation.
From @iamahuman state machine description, it looks like asyncs use "wait" operation for different things depending on the nature of the async. Some use it to "close" the async https://gitlab.winehq.org/wine/wine/-/merge_requests/6369/diffs#9c0778468c57..., others to "signal completion" (sic) https://gitlab.winehq.org/wine/wine/-/merge_requests/6369/diffs#9c0778468c57.... Is this what the cancelling thread is supposed to do on behalf of the thread normally handling the async? Using "wait" for these seems quite misleading to me.