On Fri May 2 18:16:04 2025 +0000, Matteo Bruni wrote:
As I understand it, it could change because of `async_reselect()` that's eventually called by `fd_cancel_async()` (see the comment in the `cancel_async()` function). Although IIUC that could only lower the count (if asyncs completed in the meantime), not increase it, which would allow some simplification.
Hmm... if the list can indeed change I'm thinking that the separate counting step isn't the right approach. I would suggest, instead of a cancelled flag, to keep asyncs in a dedicated list, as in https://gitlab.winehq.org/rbernon/wine/-/commits/mr/7797.
It also made me think that using wait_handle here makes things racy: if another thread waits on the async, gets it satisfied, and closes it, *after* we've returned the handle to the cancelling thread, but *before* that other thread has started waiting on it, the cancelling thread will try to wait on an invalid handle.
So, in that branch I'm creating new handles for the cancelling thread, which then each need to be closed separately. Which then possibly shows that async might need to be done differently to avoid all these roundtrips, but I'm not knowledgeable enough there.
I'm also not completely sure about putting all the cancelled asyncs in a process-wide list. Other threads cancelling async in the same process would wait on all the process previously cancelled asyncs, and maybe that would need to be done per-thread? Still, is it an issue if cancelled async are possibly short-lived?
Then, there was a change in your code that cleared the async signaled flag before cancelling it, I'm not sure why it was needed and I removed it.