On Wed Jul 23 00:39:47 2025 +0000, Elizabeth Figura wrote:
I probably haven't read the whole conversation completely, but I'm going to try to weigh in regardless:
- Asyncs are signaled when the client can return from the dispatcher
function. That means:
- If the async is blocking, the async object is signaled only once the
whole async is completed, and that includes filling the IOSB, if the IOSB needs to be filled—and note that in the case of synchronous failure it will *not* be filled.
- If the async is nonblocking, the async object is signaled once the
initial status is known, but the async itself is not necessarily complete yet. Note also that the wait on the async returns with this initial status, which can be literally anything. This is a lightweight way of returning that information that doesn't need a whole system APC. There are two cases where the initial status is not known immediately: * new-style async I/O that uses set_async_direct_result. This doesn't really matter because the client won't be waiting on the async handle until after it calls set_async_direct_result(), which will signal the async handle. * device files (only once the IRP dispatcher returns). This is the only really important case. This means that you *cannot* wait on an async to determine when it is cancelled. If it was an overlapped file handle to a device, the async handle will already be signalled. You could designal the async when cancelling it, but...
- I feel fairly strongly that async handles should not be designalled. I
think everyone else in this thread has expressed the same. Combined with the above, that means we *need* a new object to determine when an async is truly done.
I see, thanks. But even if we need a separate sync object to mark async complete completion, the server should have everything needed to know when to signal it, including the result of system APC which should deliver IOSB status. Do we really need a distinct server call to deliver notification for async completion on the client?