The AArch64 YIELD instruction affects processors that support
symmetric multithreading, while on other implementations (which
are the majority on the market) it is equivalent to NOP, thus
failing to achieve the desired delay effect inside uv__async_spin().
Instead, use the ISB instruction, following one of Arm's
recommendations [1].
[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/multi-threaded-applications-arm
Signed-off-by: Anton Kirilov <anton.kirilov@arm.com>
This fixes the test suite in environments where `/tmp` is not writable
or does not allow the use of Unix sockets, and matches the use of
relative paths elsewhere in the tests.
This apparently manifests when one passes `--cpu=.5` to docker because
then /sys/fs/cgroup/cpu.max looks like `50000 100000`, and 50000 divided
by 100000 is zero when using integer math.
Return 1 in that case, indicating there is at least one CPU available.
Returning 0 makes no sense because there is always at least one CPU
available, otherwise the program wouldn't be running.
Fixes: https://github.com/nodejs/node/issues/59200
Fix a logic bug in the fallback code for platforms that don't have a
sendmmsg-like system call. It only sent at most one packet, even when
there were more available, and that was observable through a failing
test on such systems.
Fixes: https://github.com/libuv/libuv/issues/4848
Wine has a bug (https://bugs.winehq.org/show_bug.cgi?id=50771) where
FILE_WRITE_ATTRIBUTES will cause CreateFile to fail if the file is
read-only. The recommended work around is to instead use
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE, which we do as of #4318.
However, we were still using FILE_WRITE_ATTRIBUTES to create the
initial handle, despite this no longer being required, except for
the fallback path. As a result, libuv is still broken under wine,
even on master. Fix this by removing the `FILE_WRITE_ATTRIBUTES`
from the initial CreateFile call and re-opening the handle in the
fallback path if necessary. Note that we still have the same issue
in fs_chmod and I've requested some guidance from wine on what
to do about this, but this should at least fix unlink.
Refs: https://github.com/JuliaLang/julia/issues/58980
I was testing a static analyzer on libuv's code, and it could not
understand the use of a constant variable in the condition as an assert
branch. This simplifies the code for easier static analysis. I also
removed the explicit casts, relying instead on C's casting rules to
catch some misuse.
Starting a new read after uv_read_cb returns causes memory corruption on
the OVERLAPPED read_req if uv_read_stop+uv_read_start was called during
the callback after the latest refactoring. This apparently also forces
the kernel to deadlock us, since it apparently cannot cancel the second
read while the first one is pending (reads apparently are not permitted
to finish out of order). Avoid that simply by not issuing another read
(set more=0) if there is already a read pending (from uv_read_start).
There are probably better things we could do here (such as bring back
`uv_active_tcp_streams_threshold`), but the current `alloc_cb` design
may not currently permit that without making breaking changes. We could
also detect in `uv_read_start` that we are inside of of the `read_cb`
for that stream, and defer the actual zero-read until the read_cb
returns, but that would likely be a larger change.
Fix#4738
Large-ish functions with many call sites in different translation units
should not be `static inline`, that just results in lots of code
duplication which the linker may or may not deduplicate. When it does,
the linker has to do extra work; when it doesn't, binaries get bigger.
Refs: https://github.com/libuv/libuv/issues/4819
Commit 7fb43d3c from August 2012 moved uv__atomic_exchange_set from
async.c into a header file but in all those years, nothing except
async.c has ever used it. Move the function back again and remove
the header file.
I removed the superfluous uses of inline/INLINE but this is otherwise
a non-functional change.
Refs: https://github.com/libuv/libuv/issues/4819
uv_set_process_title loads and unloads a bunch of dynamic libraries,
and that's quite slow and prone to time out when running concurrently
under AddressSanitizer.
Distinguish between errors and "the console title is the empty string"
when calling GetConsoleTitle. Both are signified by a return value of
zero.
No test because I couldn't think of a succinct way to programmatically
create a new console window with an empty title.
Fixes: https://github.com/nodejs/node/issues/58695
Implement `uv_tcp_keepalive_ex` function that extends
`uv_tcp_keepalive` to support `TCP_KEEPINTVL` and `TCP_KEEPCN`
socket options in addition to TCP_KEEPIDLE.
The documentation is referring to an internal name -
UV_LOOP_ENABLE_IO_URING_SQPOLL - in several places. Fix this by using
the public UV_LOOP_USE_IO_URING_SQPOLL name instead.
