On Mon May 5 14:48:08 2025 +0000, Rémi Bernon wrote:
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.
I'm probably missing a lot of context, but the very idea of returning a variably sized list for the client to wait isn't appealing to meeither.
Instead, we should probably define a new async op (via `create_request_async`) for the cancelling operation itself. Just a separate event isn't enough, since we need proper IOSB management for the cancelling operation itself (note that NtCnacelIoFile accepts *two* IOSBs.)