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 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
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
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.
Handle out-of-memory conditions in uv_loop_init better, albeit still
not perfect: bubble up the error instead of aborting.
Also fixes a file descriptor leak on Linux (and likely other platforms)
that the new test caught; the backend epoll fd was being leaked in the
error path.
Fixes: https://github.com/libuv/libuv/issues/4755
Haiku has parallel types to stdint.h, and their APIs use these
types. In the Haiku-specific haiku.h file, it is passing an
address of a uint32_t to get_cpu_topology_info(), that expects
the other uint32:
648fa5897c/src/system/libroot/os/system_info.cpp (L187)
You get an "incompatible-pointer-types" warning in gcc if the
warnings are turned up. But if you pass the pointer to Haiku's
notion of uint32, then the warning goes away.
On some platforms (like GNU/Hurd), `getsockname` returns an empty
string for sockets in the UNIX domain. However, we do have stored the
path info in `pipe_fname` of `uv_pipe_t`, so we can try with it
if `getsockname` returns an empty string.
Use fchmod() on platforms that support it on UNIX sockets. Only fall
back to chmod() on platforms that don't (macOS and the BSDs.)
Remove the stat + chmod dance from the fallback and just call chmod
directly, because that's another source of TOCTOU issues.
Fixes: https://github.com/libuv/libuv/issues/2040
Documentation on Linux explains that nul bytes have no
special significance in abstract namespace socket names.
Avoid precluding such addresses.
Signed-off-by: Itay Bookstein <ibookstein@gmail.com>
Solaris 11.4 has Load Balancing for SO_REUSEPORT, but setting
SO_REUSEADDR disables load balancing. As per comments in
test/test-udp-reuseport.c prefer SO_REUSEPORT when available.
With these changes in place udp-reuseport testing passes. BIND (named),
which uses routing sockets which cause ENOPROTOOPT to be returned when
SO_REUSEPORT is requested, also continues to work with the change.
Notes:
- The use of getsockopt() to query if SO_REUSEPORT was available was
erroneous.
- Selectively limiting SO_REUSEPORT setting to specific types of socket
was considered but not entertained.
- Oracle will investigate if the setting of SO_REUSEADDR was
intentionally meant to prevent load balancing.
- Adding a test for routing sockets is left for future work.
On OpenBSD we do not know the cpuspeed in same cases (mostly arm64)
and the HW_CPUSPEED sysctl will return EOPNOTSUPP in that case,
which can be ignored because we still need the rest of the CPU
information.
Solaris provides sendmmsg() as of 11.3.32.
It was added at the same time as MSG_WAITFORONE.
The same is seen in Illumos guarded by __BSD_VISIBLE
Fixes: https://github.com/libuv/libuv/issues/4715
Windows provides the `ENABLE_VIRTUAL_TERMINAL_INPUT` flag for TTY input
streams as a companion flag to `ENABLE_VIRTUAL_TERMINAL_PROCESSING`,
which libuv is already setting for TTY output streams.
Setting this flag lets the terminal emulator perform some of the
processing that libuv already currently does for input events,
but most notably enables receiving control sequences that are
otherwise entirely unavailable, e.g. for bracketed paste
(which the Node.js readline implementation added basic support for
in https://github.com/nodejs/node/commit/87af913b66eab78088acfd).
libuv currently already provides translations for key events to
control sequences, i.e. what this mode is intended to provide,
but libuv does not and cannot translate all such events.
Since the control sequences differ from the ones that Windows
has chosen to standardize on, and applications may not be expecting
this change, this is opt-in for now (but ideally will be the default
behavior starting in libuv v2.x, should that ever happen).
Another downside of this change is that not all shells reset
this mode when an application exits. For example, when running a
Node.js program with this flag enabled inside of PowerShell in
Windows terminal, if the application exits while in raw TTY input mode,
neither the shell nor the terminal emulator reset this flag, rendering
the input stream unusable.
While there's general awareness of the problem that console state is
global state rather than per-process (same as on UNIX platforms),
it seems that applications like PowerShell aren't expecting to need to
unset this flag on the input stream, only its output counterpart
(e.g. 4e7942135f/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHost.cs (L1156)).
Hence, `uv_tty_reset_mode()` is extended to reset the terminal
to its original state if the new mode is being used.
Refs: 87af913b66
Refs: https://github.com/microsoft/terminal/issues/4954
Extend uv_fs_utime, uv_fs_futime and uv_fs_lutime to accept NAN and
INFINITY, with NAN meaning "don't touch the timestamp" and INFINITY
meaning "set to the current timestamp."
Ugly, but it avoids having to add uv_fs_utime2, etc.
UV_FS_UTIME_NOW and UV_FS_UTIME_OMIT constants have been added to make
it more palatable.
Fixes: https://github.com/libuv/libuv/issues/4665
