Sorry, which one (the link covers discussion for different topics, can't easily deduce where exactly it points to).
Sorry, gitlab sucks for this :rolling_eyes: The first one, which you guessed correctly, was:
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.
Which is seen at line +616 in server/async.c (version 1 of the MR, you can get to that from the Changes tab if you select "version 1" from the second dropdown menu).
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).
It does not. The async is set to `signaled` right away, so that Status can be set to STATUS_PENDING and subsequently checked via `GetOverlappedResult()`. But I see the point. I'll look for some way to do it without "unsignaling" the async.
The other one I have no problem with. I originally waited for the handles one by one with server_select() directly, like from line +6464 of dlls/ntdll/unix/file.c onwards (again "version 1"). I changed that to `NtWaitForMultipleObjects()` afterwards because of some review comment.