We will always call set_fd_events() again in sock_reselect().
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Asyncs which are alerted but not "waiting" may still fill the pipe, and we
shouldn't signal AFD_POLL_WRITE in that case.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Asyncs which are alerted but not "waiting" may still consume all data, and we
shouldn't signal AFD_POLL_READ or AFD_POLL_OOB in that case.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is validated by tests introduced in
59beffb46c etc. This commit alone doesn't fix said
tests, because:
* on this poll, we will alert the waiting async;
* when reselecting, we will still request POLLIN, because the AFD_POLL_READ
request is still active,
* when POLLIN is subsequently signaled, we do not remove it in
sock_dispatch_asyncs(), because we check async_waiting(), not async_queued().
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The 'status' field of send_socket_request is always either
STATUS_PENDING or STATUS_DEVICE_NOT_READY, and the 'total' field is
always zero.
Replace the 'status' field with 'force_async' boolean field, and get rid
of the 'total' field entirely.
Also, clean up the send_socket handler code a bit.
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 type of the socket is SOCK_DGRAM, it shall always be bound to an
address if we ever attempt to send datagrams through the socket, whether
the attempt succeeds or not.
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>
Make send_socket alert the async immediately if poll() call detects that
there are incoming data in the socket, bypassing the wineserver's main
polling loop.
For sock_transmit, we always mark the async as pending and set the IOSB
(unless async allocation has failed).
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>
This allows the initial I/O to be performed after the send_socket
handler is called.
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 'status' field of recv_socket_request is always either
STATUS_PENDING or STATUS_DEVICE_NOT_READY, and the 'total' field is
always zero.
Replace the 'status' field with 'force_async' boolean field, and get rid
of the 'total' field entirely.
Also, clean up the recv_socket handler code a bit.
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>
Make recv_socket alert the async immediately if poll() call detects that
there are incoming data in the socket, bypassing the wineserver's main
polling loop.
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>
Fixes a regression introduced by
5c009c17b3.
For IPV6 socket already bound with bind() with IPV6_V6ONLY set to 0
the address returned by getsockname() may change after it is connected
to a IPV4 peer (e. g., from :: to ::ffff:192.0.2.128).
The effect of blamed commit is that before that Unix getsockname()
was called for each ws2_32 getsockname() and after the commit the
socket name is cached at bind and connect.
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Ideally we should be using sock_get_poll_events() and sock_poll_event() instead,
but that seems like an overly risky change for this late in code freeze.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51442
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>
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>
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>
Zebediah Figura