This also makes async_handoff() behaviour more consistent with
async_set_result() for handling I/O failures.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Today, async_set_completion_callback() is used to register a function
that is called when the async I/O is completed. It is assumed that the
async will eventually be queued when such callback is registered.
However, this incurs extra complexity in future code that needs the
completion logic to be invoked even if the async is never actually
queued (e.g. when the I/O failed synchronously before async_handoff).
Generalise async completion callback by calling it in async_handoff()
when the I/O status indicates failure.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The client can set mark_pending to indicate that the full-blown I/O
completion mechanism shall be triggered (asynchronous completion) even
if the status indicates failure.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Shift the resposibility of setting initial status from
set_async_direct_result request handler to async_set_result().
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Commit 15483b1a12 (server: Allow calling async_handoff() with status
code STATUS_ALERTED., 2022-02-10) introduced the set_async_direct_result
handler which calls async_set_initial_status().
However, the async_set_initial_status() call does nothing since
async->terminated is set, leaving the async in a confusing state
(unknown_status = 1 but pending/completed).
So far, this issue is unlikely to have been a problem in practice for
the following reasons:
1. async_set_initial_status() would have unset unknown_status, but it
remains set instead. This is usually not a problem, since
unknown_status is usually ever read by code paths effectively
unreachable for non-device (e.g. socket) asyncs.
It would still potentially allow set_async_direct_result to be called
multiple times, but it wouldn't actually happen in practice unless
something goes wrong.
2. async_set_initial_status() would have set initial_status; however,
it is left with the default value STATUS_PENDING. If the actual
status is something other than that, the handler closes the wait
handle and async_satisfied (the only real consumer of initial_status)
would never be called anyway.
For reasons above, this issue is not effectively observable or testable.
Nonetheless, the current code does leave the async object in an
inconsistent state.
Fix this by removing the !async->terminated check in
async_set_initial_status().
Also, remove assert( async->unknown_status ). The client can now
trigger the assert() by calling set_async_direct_result on a device
async, thereby causing async_set_initial_status() to be called twice.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If the server detects that an I/O request could be completed immediately
(e.g. the socket to read from already has incoming data), it can now
return STATUS_ALERTED to allow opportunistic synchronous I/O. The Unix
side will then attempt to perform I/O in nonblocking mode and report
back the I/O status to the server via the new server request
"set_async_direct_result". If the operation returns e.g. EAGAIN
or EWOULDBLOCK, the client can opt to either abandon the request (by
specifying an error status) or poll for it in the server as usual (by
waiting on the wait handle).
Without such mechanism in place, the client cannot safely perform
immediately satiable I/O operations synchronously, since it can
potentially conflict with other pending I/O operations that have already
been queued.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, async_waiting() returns 0, leading the socket object to
believe that the previous async request has not yet been acknowledged.
This results in I/O hang for subsequent reads (until shutdown).
Also, async_destroy() calls async_reselect() only after removing the
async request from the queue. Make async_set_result() consistent with
this behaviour.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52332
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Only really an optimization (plus it makes the code a little conceptually simpler).
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch by Chip Davis.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=30155
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of manually specifying success or failure.
Based on test_return_status() in ntoskrnl. The changes in this patch don't
affect device IRPs, but the tests show the heuristic that Windows uses, and in
practice it turns out to be correct for all known asyncs.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Mostly just to simplify the interface, so that we don't need to use the return
value to communicate this.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In particular, don't mark asyncs with output data as "alerted", i.e.
restartable.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For convenience, and to centralize the STATUS_ALERTED logic into one place.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We still don't quite handle this completely correctly, but we should at least
avoid crashing the server due to a failed assertion.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
At best this is a no-op. At worst this will emit an extra APC_ASYNC_IO where
the termination (e.g. cancellation) should already have emitted one.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If the async has not been terminated yet, async->fd cannot be NULL.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This was used to implement AcceptEx() using multiple APCs, and made obsolete by
0bbd3f6617.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This semantically reverts 481517178f.
That commit was used to implement NtFlushBuffersFile, which at the time didn't
use a callback function. 9050b58f07 changed it to
use irp_completion(), since the result of a blocking flush needed to be taken
from the IOSB.
As of 97afac469f that's not true anymore, but on
the other hand it is theoretically possible for a device driver to touch the
Information member of the IOSB, and we don't seem to lose anything by making
all asyncs take a common path.
Since all asyncs pass user data and there's no clear reason for them not to,
let's get rid of a bit of extra code complexity that's no longer used.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Steam uses WSASend() with completion ports, reusing OVERLAPPED structures as
soon as they are returned from GetQueuedCompletionStatus(). Since completion is
queued during the select request in wait_async(), the I/O status block can be
reused even before the call to NtDeviceIoControl exits.
This works fine with current Wine, because WSASend() doesn't access the I/O
status block after queuing completion. However, a patch that changes it to use
wait_async() like other async requests causes NtDeviceIoControlFile to
consistently return garbage status codes.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Jinoh Kang