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.
Calling uv_fs_fstat for file types other then disk type was resulting in
error on Windows while it was retrieving data on Linux. This change
enables getting fstat for pipes and character files on Windows with data
fetched being as reasonable as possible.
A simple test is also added to check this behavior on all platforms. It
uses stdin, stdout and stderr. uv_fs_fstat needs to pass with disk files
pipes and character files (eg. console).
Refs: https://github.com/nodejs/node/issues/40006
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
The old Linux baseline was essentially RHEL 6 but that distro has been
out of support for two years now. Move to RHEL 7.
This commit also moves FreeBSD to tier 2 because it isn't actually
part of libuv's CI matrix, only Node's.
Fixes: https://github.com/libuv/libuv/issues/3822
The following metrics are now always recorded and available via the new
uv_metrics_info() API.
* loop_count: Number of event loop iterations.
* events: Total number of events processed by the event handler.
* events_waiting: Total number of events waiting in the event queue when
the event provider request was made.
Benchmarking has shown no noticeable impact recording these metrics.
PR-URL: https://github.com/libuv/libuv/pull/3749
Make unices and windows consistent when closing a pipe while it's
connecting so they all return `UV_ECANCELED`.
Avoid race condition between `pipe_connect_thread_proc()` and `uv_close()` when
accessing `handle->name`.
Fixes: https://github.com/libuv/libuv/issues/3578
This reverts commit 87f0765159 and
implements a work-around instead. This has been reported to be
unnecessary, and also returns the wrong answer (off by exactly 100x),
so it is not particularly useful.
This also reverts the bugfixes to the original PR:
Revert "darwin: fix iOS compilation and functionality"
This reverts commit 1addf9b88a.
Revert "macos: fix the cfdata length in uv__get_cpu_speed (#3356)"
This reverts commit 1e7074913e.
Revert "darwin: fix -Wsometimes-uninitialized warning"
This reverts commit 6085bcef8d.
Revert "macos: fix memleaks in uv__get_cpu_speed"
This reverts commit d2482ae121.
The expected behavior on failure to read this info is to report 0 (for
example
https://github.com/libuv/libuv/blob/8975c05d199558b0cc2e98f26ce33c6090d1
d7a1/src/unix/linux.c#L834), which is which was not the case before
this PR for macos.
However hw.cpufrequency sysctl seems to be missing on darwin/arm64
(Apple Silicon), so we instead hardcode a plausible value. This value
matches what the mach kernel will report when running Rosetta apps.
Fixes: https://github.com/libuv/libuv/issues/3642
Fixes: https://github.com/libuv/libuv/issues/2911
Refs: https://github.com/libuv/libuv/pull/2912
Backported thread affinity feature and related dependency commits
from master. It will add support for those APIs: uv_cpumask_size,
uv_thread_setaffinity, uv_thread_getaffinity.
The supported platforms are Linux, Freebsd, and Windows.
Empty implementations (returning UV_ENOTSUP) on non-supported platforms
(such as OS X and AIX).
In the old version of uv_pipe_open, the parent process ID is used
always. If the open pipe is used in the same process, the parent
process will be obtained incorrectly.
Now we first get the client pid and compare it with its own pid. If it
is the same, then get the server pid. If the two are the same, then the
pipe is from the same process.
Fixes: https://github.com/libuv/libuv/issues/3766
- unpoison results from linux system call wrappers
- unpoison results from stat/fstat/lstat to pacify clang 14
(fixed in later versions)
- add MSAN build option
- turn on MSAN CI build
I split up linux.c around 2012 for no real reason and now I'm merging
it back together, again for no real reason.
I half-jest. I like the idea of having everything together because I
practically forgot linux-inotify.c existed. It also makes io_uring
experiments a little easier.
Last but not least, it removes about 100 lines of license boilerplate.
preadv, pwritev, dup3 and utimensat all exist in 2.6.32 kernels, libuv's
minimum supported kernel.
The wrapper for utimensat was already gone, only the define remained.
uv_fs_scandir() leaked an entry when you called it on a directory with
a single entry _and_ you didn't run the iterator until UV_EOF.
Fixes: https://github.com/libuv/libuv/issues/3748
epoll.c is only used on Android and Linux after commit 5fe59726 ("sunos:
restore use of event ports") so move it back into linux-core.c
This commit removes a workaround for pre-2.6.27 kernels that don't have
the epoll_create1() system call.
Remove the TODO that says to batch up kevent(EV_DELETE) system calls.
It's unduly complicated in case of errors.
If you pass an out array to kevent(), it will store error records that
tell you which file descriptor caused the error but it also stores new
events in the array, complicating state management.
If you don't pass an out array, it simply doesn't tell you anything
except that _something_ failed. Optimistically trying batch deletion
and falling back to one-by-one deletion is probably possible but is
something of a deoptimization and also feels somewhat dangerous.
macOS has a mostly-undocumented kevent_qos() system call that accepts a
KEVENT_FLAG_ERROR_EVENTS flag that fixes the first problem but that of
course isn't portable.
Long story short, it seems like too much hassle for too little payoff.
Libuv has been doing one-by-one deletion for over a decade now and no
one complained about performance so far so let's just stick with that.
Another thread can change the working directory between calls to
GetCurrentDirectoryW().
The first call was used to determine the size of the buffer to use in
the second call. Retry if the reported size does not match the expected
size because the buffer's contents is undefined in that case.
uv_exepath() wrote the nul byte *after* the end of the buffer. It's not
necessary to write said nul byte in the first place because that was a
workaround for a bug in the Windows XP version of GetModuleFileName().
Fix uv_cwd() in the same fashion, it doesn't need the nul byte either.
Fixes: https://github.com/libuv/libuv/issues/3691
After analysis of many real-world programs I've come to conclude that
accepting in a loop is nearly always suboptimal.
1. 99.9% of the time the second accept() call fails with EAGAIN, meaning
there are no additional connections to accept. Not super expensive
in isolation but it adds up.
2. When there are more connections to accept but the listen socket is
shared between multiple processes (ex. the Node.js cluster module),
libuv's greedy behavior necessitated the UV_TCP_SINGLE_ACCEPT hack
to slow it down in order to give other processes a chance.
Accepting a single connection and relying on level-triggered polling to
get notified on the next incoming connection both simplifies the code
and optimizes for the common case.
This was a kludge for a bug in old versions (API level <= 16) of the
Android SDK.
The os390 port had a build dependency on the file but does not actually
use it so that too has been removed.
Split this off from endgame, so that it can be handled separately and
earlier, rather than trying to detect inside endgame which case we are
in. There appear to be some race conditions on the `handle` field still
however, which this does not yet attempt to address.
