musl libc doesn't supply any definitions for IPX, such as the SOL_IPX
macro. However, it still provides linux/ipx.h from Linux uAPI header
files if it exists.
Linux kernel wouldn't drop linux/ipx.h from uAPI headers until 5.15,
although IPX support has already been marked obsolete since 2018.
Fix this by not defining HAS_IPX if linux/ipx.h has been included but
nothing defines the SOL_IPX macro.
Status of IPX support from other libcs are noted below:
- bionic: netipx/ipx.h does not exist. linux/ipx.h may or may not
exist. Note that sys/socket.h defines SOL_IPX even if linux/ipx.h is
missing.
- glibc: netipx/ipx.h exists. In this case, Wine assumes IPX support
even if the operating system does not support it in runtime.
- BSD variants: netipx/ipx.h may or may not exist. linux/ipx.h does not
exist. Some BSDs supply SO_DEFAULT_HEADERS instead of SOL_IPX.
Fixes: 41cc117b3f
foobar2000.exe's UPnP Media Renderer component (foo_out_upnp.dll)
expects that, if a select() call completes successfully with a non-empty
writefds set, any immediately following send() call on a socket in the
writefds set never fails with WSAEWOULDBLOCK.
On Wine, the Winsock select() and send() implementations both call the
Unix poll(2) under the hood to test if I/O is possible on the socket.
As it turns out, it's entirely possible that Linux poll() may yield
POLLOUT on the first call (by select) but *not* the second (by send),
even if no send() call has been made in the meanwhile.
On Linux (as of v5.19), a connected (ESTABLISHED) TCP socket that has
not been shut down indicates (E)POLLOUT only if the ratio of
sk_wmem_queued (the amount of bytes queued in the send buffer) to
sk_sndbuf (the size of send buffer size itself, which can be retrieved
via SO_SNDBUF) is below a certain threshold. Therefore, a falling edge
in POLLOUT can be triggered due to a number of reasons:
1. TCP fragmentation. Once a TCP packet is split out from a larger
sk_buff, it incurs extra bookkeeping overhead (e.g. sk_buff header)
that is counted in sk_wmem_queued alongside application data.
See also: tcp_fragment(), tso_fragment() (Linux 5.19).
2. Control packets (e.g. MTU probing). Such packets share the same
buffer with application-initiated packets, and thus counted in
sk_wmem_queued.
See also: sk_wmem_queued_add() callers (Linux 5.19).
3. Memory pressure. This causes sk_sndbuf to shrink.
See also: sk_stream_moderate_sndbuf() callers (Linux 5.19).
Fix this by always attempting synchronous I/O first if req->force_async
is unset and the nonblocking flag is set.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53486
In multiple cases errors may be reported only once by the host socket
implementation, but should persist for Windows sockets. These cases are
currently not handled by poll_socket().
poll_socket() also does not include logic for filtering out events when asyncs
are queued or alerted on the relevant socket.
Hence, instead of duplicating more logic, remove the logic already duplicated,
and just call sock_poll_event(), so that there is one central place where events
are translated.
Mark the currently active poll async with a special "pending" field so that
poll_socket() does not attempt to complete it before all sockets are checked.
This reverts commit 24b64534e5.
We no longer perform any blocking waits on the client side, so shutdown() is no
longer necessary.
Moreover, shutting down is not always correct. Under some conditions, closing a
TCP socket should trigger RST without FIN (namely, when SO_LINGER is on but has
a zero timeout). By reverting this commit we match Windows behaviour in this
respect.
.NET 6's HTTP/Socket code queries this. Winsock allows getsockname
on the AcceptEx AcceptSocket, but only if SO_UPDATE_ACCEPT_CONTEXT
is set.
Signed-off-by: David Curtiss <david.curtiss@ni.com>
Otherwise socket error may be cleared in poll_socket causing ioctl SO_ERROR calls to return no error.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51433
Signed-off-by: Piotr Caban <piotr@codeweavers.com>
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>
