Don't use rd_shutdown and wr_shutdown to determine this. On the one hand, it's
possible to have pending asyncs even if rd_shutdown && wr_shutdown, which will
be cheerfully completed upon receiving data. On the other hand, RST doesn't
cause WSAESHUTDOWN, but rather WSAECONNRESET.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch by Torge Matthies.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51319
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This patch does result in one functional change: if we are selecting for
AFD_POLL_READ on a socket which has had SD_RECEIVE and there are no asyncs, we
will now respond to POLLIN instead of ignoring it. Neither this nor the previous
behaviour matches Windows, which instead puts the socket into an aborted state
and sends RST to the peer if any data is received after SD_RECEIVE or if
SD_RECEIVE is done while there is pending data.
Apart from this there is no functional change, as the places where rd_shutdown
alone is checked can't be reached if there was a hangup. It is instead for
semantic clarity.
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 fixes a regression introduced by 97afac469f.
If we make a request on an asynchronous device handle, and the IRP handler
returns STATUS_PENDING, wait_async() will return STATUS_PENDING, as intended.
However, if the async object is signaled before the user has a chance to call
wait_async() [e.g. if get_next_device_request is called quickly enough], select
will return STATUS_PENDING immediately, which causes server_select() to think
the object is not signaled, and wait for a select reply forever.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51277
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51295
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Several server objects check if the last handle is being closed in their
close_handle callback. If a process holds the last two handles to an object,
this code path currently won't be triggered.
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>
This fixes a server crash that can be triggered by deleting a key and then
trying to retrieve its name. In that case key->parent is NULL.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
A deleted key returns STATUS_KEY_DELETED when ObjectNameInformation is
requested, but succeeds when ObjectBasicInformation is requested.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard