In the case of trying to write more than `IOV_MAX` buffers, the
`IORING_OP_WRITEV` operation will return `EINVAL`. As a temporal fix,
fallback to the old ways. In the future we might implement this by
linking multiple `IORING_OP_WRITEV` requests using `IOSQE_IO_LINK`.
Instead of suppressing the VLA warning, use a fixed-size buffer that is
big enough to receive at least one control message but not so big that
IBMi PASE rejects it.
When there are more than 128 concurrent cq completions the CQ ring
overflows as signaled via the `UV__IORING_SQ_CQ_OVERFLOW`. If this
happens we have to enter the kernel to get the remaining items.
This commit adds the ability to dump core when sending the `SIGQUIT`
signal on Windows. The change reads in the current registry setting for
local dumps, and attempts to write out to that location before killing
the process. See [collecting-user-mode-dumps] for registry and pathing
details. This behavior mimics that of the dumps created by the typical
Windows Error Reporting mechanism.
[collecting-user-mode-dumps]: https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps
* Revert "macos: fix source not being followed when cloning (#3941)"
This reverts commit 507f2f950d.
* Revert "darwin: bring back macos-specific copyfile(3) (#3654)"
This reverts commit d4eb276eea.
The worker pool calls all callbacks locally within the queue. So the
value of nevents doesn't properly reflect that case. Increase the number
of events directly from the worker pool's callback to correct this.
In order to properly determine if the events_waiting counter needs to be
incremented, store the timeout value at the time the event provider was
called.
Fix a valgrind warning that only manifested with clang (not gcc!) by
explicitly passing 0L instead of plain 0 as the |sigsz| argument to
io_uring_enter(). That is, pass a long instead of an int.
On x86_64, |sigsz| is passed on the stack (the other arguments are
passed in registers) but where gcc emits a `push $0` that zeroes the
entire stack slot, clang emits a `movl $0,(%rsp)` that leaves the upper
32 bits untouched.
It's academic though since we don't pass IORING_ENTER_EXT_ARG and the
kernel therefore completely ignores the argument.
Refs: https://github.com/libuv/libuv/pull/3952
Add io_uring support for several asynchronous file operations:
- read, write
- fsync, fdatasync
- stat, fstat, lstat
io_uring is used when the kernel is new enough, otherwise libuv simply
falls back to the thread pool.
Performance looks great; an 8x increase in throughput has been observed.
This work was sponsored by ISC, the Internet Systems Consortium.
Fixes: https://github.com/libuv/libuv/issues/1947
Issue observed on Solaris with ISC BIND 9.18 which reported "unable to
open route socket: unexpected error". illumos did not hit it because it
does not have SO_REUSEPORT (open RFE
https://www.illumos.org/issues/12455)
The last major distro that supported the oabi calling convention was
Debian 5 (Lenny) and that went out of support in February 2012. It seems
like a fairly safe assumption that nothing speaks oabi anymore in this
day and age.
Fixes: https://github.com/libuv/libuv/issues/3935
Replace the throw-type-safety-to-the-wind CAST() macro with an inline
function that is hopefully harder to misuse. It should make the inotify
code slightly more legible if nothing else.
The maximum number of times timers should run when uv_run() is called
with UV_RUN_ONCE and UV_RUN_NOWAIT is 1. Do that by conditionally
calling timers before entering the while loop when called with
UV_RUN_DEFAULT.
The reason to always run timers at the end of the while loop, instead of
at the beginning, is to help enforce the conceptual event loop model.
Which starts when entering the event provider (e.g. calling poll).
Other than only allowing timers to be processed once per uv_run()
execution, the only other noticeable change this will show is if all the
following are true:
* uv_run() is called with UV_RUN_NOWAIT or UV_RUN_ONCE.
* An event is waiting to be received when poll is called.
* Execution time between the call to uv_timer_start() and entering the
while loop is longer than the timeout.
If all these are true, then timers that would have executed before
entering the event provider will now be executed afterward.
Fixes: https://github.com/libuv/libuv/issues/3686
Co-authored-by: Momtchil Momtchev <momtchil@momtchev.com>
This code would previously get confused between rounds of the barrier
being called and a thread might incorrectly get stuck (deadlock) if the
next round started before that thread had exited the current round.
Avoid that by not starting the next round in++ before out-- has reached
zero indicating that all threads have left the prior round.
And fix it that on Windows by replacing the implementation with the one
from unix. There are some awkward platform-specific redirection here
with an extra malloc that is not needed on Win32, but that will be fixed
in libuv v2.
Fixes: https://github.com/libuv/libuv/issue/3872
The call to uv__cwd() always returns a new allocation. The previously
allocated utf16_buffer needs to be free'd before passing it in to
receive the next allocation.
ThreadSanitizer complains about unsynchronized access to the
handle->loop->cf_state pointer.
The warning is probably benign but the fsevents thread already knows
the pointer. It doesn't have to read it, it just needs to propagate it.
Refs: https://github.com/libuv/libuv/issues/3880
The conditional bind-to-port logic in tcp.c had an error path that
closed the socket file descriptor while it was still owned by the
uv_tcp_t handle.
Fix that by not closing the file descriptor and refactoring the code so
it is hopefully harder to get wrong in the future.
The refactoring also makes the code a little flatter, removes duplicated
code, and, arguably, is in a more idiomatic libuv style.
Fixes: https://github.com/libuv/libuv/issues/3461
Replaces: https://github.com/libuv/libuv/pull/3462
Co-authored-by: Ben Noordhuis <info@bnoordhuis.nl>
Since we are emulating this event, but are not using the pending_queue,
we need to make sure it is accounted for properly. Also DRY some of the
reset_timeout code here.
This was observed to cause a hang in certain rare cases, particularly on
M1 machines.
Do a bit of code cleanup too, since we do not need to initialize the
internal signal handling pipe if it will not be used.
The current fix (libuv#2231) was found to be slow in certain cases. This
change should improve scalabaility a bit by only incurring the spin loop
delay while closing an UV_ASYNC. It also is intended to slightly improve
the behavior after uv_loop_close is called, by parking all of the
pending flags as set, so that it will not access the loop at all (until
the uv_async_t memory is freed, which we leave still to the
responsibility of the user).
Note that this bug appears to still exist on Win32, though it's harder
to address without the refactoring done to this code on libuv master.
Takes some inspiration from https://github.com/libuv/libuv/pull/2654
Takes some inspiration from https://github.com/libuv/libuv/pull/2656
Refs: https://github.com/libuv/libuv/pull/2231
File system operations may return uid and gid values, which we may want
to pretty-print. We already have the code for getting information for
the current user, so just need to add a parameter to make it exposed for
every user. We expose information about groups in a similar manner also.
In Node.js, fs.readlink() on a non-symlink file used to throw an UNKNOWN
error on Windows. This change maps ERROR_NOT_A_REPARSE_POINT to
UV_EINVAL, so that now it throws EINVAL just like other platforms.
This is handled explicitly in `fs__readlink`, since elsewhere it might
map to EPERM instead (such as in `link`).
On Linux, CPUs can come online or go offline while uv_cpu_info() is busy
gathering data. Change uv_cpu_info() in the following ways:
1. Learn online CPUs from /proc/stat
2. Get the model name from /proc/cpuinfo when it has a matching CPU,
or default to "unknown"
3. Get speed from /sys/devices/system/cpu/cpu%u/cpufreq/scaling_cur_freq
when it exists, or default to 0
Before this commit, libuv read the speed from /proc/cpuinfo but that
reports the base frequency, not the actual frequency. My system has
two cores running permanently at 3.6 GHz but libuv thought all 12 ran
at 2.2 GHz.
Fixes: https://github.com/libuv/libuv/issues/2351
Fixes: https://github.com/libuv/libuv/issues/3858
Return `UV_EAGAIN` on `ERROR_OPERATION_ABORTED`.
Use the correct format for `overlapped.hEvent`.
Some refactoring to always wait for the overlapped result.
Modernize tests and some improvements.
