This switches uv_cpu_info from using sysctlbyname to
using IOKit to get the speed of the processors.
macOS on ARM does not currently have the hw.cpufrequency
sysctl. We are able to reliable get the clock frequency
on all architectures by using IOKit.
Fixes: https://github.com/libuv/libuv/issues/2911
PR-URL: https://github.com/libuv/libuv/pull/2914
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
No functional changes are intended [NFCI], but this may make it easier
in the future to implement and respect the `modes` flag.
PR-URL: https://github.com/libuv/libuv/pull/2921
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
The API addition `uv_metrics_idle_time()` is a thread safe call that
allows the user to retrieve the amount of time the event loop has spent
in the kernel's event provider (i.e. poll). It was done this way to
allow retrieving this value without needing to interrupt the execution
of the event loop. This option can be enabled by passing
`UV_METRICS_IDLE_TIME` to `uv_loop_configure()`.
One important aspect of this change is, when enabled, to always first
call the event provider with a `timeout == 0`. This allows libuv to know
whether any events were waiting in the event queue when the event
provider was called. The importance of this is because libuv is tracking
the amount of "idle time", not "poll time". Thus the provider entry time
is not recorded when `timeout == 0` (the event provider never idles in
this case).
While this does add a small amount of overhead, when enabled, but the
overhead decreases when the event loop has a heavier load. This is
because poll events will be waiting when the event provider is called.
Thus never actually recording the provider entry time.
Checking if `uv_loop_t` is configured with `UV_METRICS_IDLE_TIME` always
happens in `uv__metrics_set_provider_entry_time()` and
`uv__metrics_update_idle_time()`. Making the conditional logic wrapping
each call simpler and allows for instrumentation to always hook into
those two function calls.
Rather than placing the fields directly on `uv__loop_internal_fields_t`
add the struct `uv__loop_metrics_t` as a location for future metrics API
additions.
Tests and additional documentation has been included.
PR-URL: https://github.com/libuv/libuv/pull/2725
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Add struct `uv__loop_internal_fields_t` as a location for future
additions to `uv_loop_t` while also maintaining v1.x compatibility.
Currently `uv__loop_internal_fields_t` only contains the `flags` field.
The reason for adding the `flags` field is because the same field was
never added to `UV_LOOP_PRIVATE_FIELDS` in Windows as it was in Unix.
The idea for creating a struct and attaching it to `uv_loop_t` for
future API enhancements was taken from a comment by bnoordhuis in:
https://github.com/libuv/libuv/issues/2506#issuecomment-540050665
Also add `internal_fields` to `uv_loop_t` to store the pointer to
`uv__loop_internal_fields_t`. This naming makes more sense than just
using `active_reqs.unused[1]`. To maintain ABI compatibility, shrink the
`unused` array.
PR-URL: https://github.com/libuv/libuv/pull/2725
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This is a port of 70002c80 to z/OS to fix the same potential issue that
could effectively enter an infinite loop (but not a busy loop) under
certain conditions when polling for events.
PR-URL: https://github.com/libuv/libuv/pull/2725
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Allows for determining if a buffer large enough for multiple dgrams
should be allocated in alloc_cb of uv_udp_recvstart, for example.
Contributes towards #2822.
PR-URL: https://github.com/libuv/libuv/pull/2830
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This fix avoids inserting a duplicate pending request in the case where
`WSARecv()` returns an error (e.g. when a connection has been terminated
by its peer) when `uv_read_start()` is called in a read callback.
Fixes: https://github.com/libuv/libuv/issues/2687
PR-URL: https://github.com/libuv/libuv/pull/2688
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
PR-URL: https://github.com/libuv/libuv/pull/2895
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
This was part of commit c70dd705 ("unix: use relaxed loads/stores for
feature checks") and was reviewed as such but I accidentally dropped
it in the rebase before the final merge.
Fixes: https://github.com/libuv/libuv/issues/2884
PR-URL: https://github.com/libuv/libuv/pull/2886
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This issue manifested on `connected` udp sockets trying to send
datagrams to a non-existent server and returning `ECONNREFUSED` because
an ICMP error was received before the actual sending was performed.
PR-URL: https://github.com/libuv/libuv/pull/2899
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
It was reported that mach_absolute_time() can jump backward in time when
the machine is suspended. Use mach_continuous_time() when available to
work around that (macOS 10.12 and up.)
Fixes: https://github.com/libuv/libuv/issues/2891
PR-URL: https://github.com/libuv/libuv/pull/2894
Reviewed-By: Phil Willoughby <philwill@fb.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
`__atomic_load_n()` and friends were added in gcc 4.7.0 but we still
have some centos6 machines with a vintage gcc 4.4.7 from 2012 in the
CI matrix.
PR-URL: https://github.com/libuv/libuv/pull/2888
Refs: https://github.com/libuv/libuv/pull/2886
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Make ThreadSanitizer stop complaining about the static variables that
libuv uses to record the presence (or lack) of system calls and other
kernel features.
Fixes: https://github.com/libuv/libuv/issues/2884
PR-URL: https://github.com/libuv/libuv/pull/2886
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
The variable uv__read_console_status is left as IN_PROGRESS when the
operation is canceled ahead of time by the main thread requesting a
trap (race condition?).
This confuses the next call to uv__cancel_read_console(...) causing
a deadlock due to a semaphore acquisition that is never released by
the reading thread.
Setting the status variable back to COMPLETE or NOT_STARTED fixes
the issue.
Ref: https://github.com/nodejs/node/issues/32999
PR-URL: https://github.com/libuv/libuv/pull/2882
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
It was reported that uv_loadavg() reports the wrong values inside an
lxc container.
Libuv calls sysinfo(2) but that isn't intercepted by lxc. /proc/loadavg
however is because /proc is a FUSE fs inside the container.
This commit makes libuv try /proc/loadavg first and fall back to
sysinfo(2) in case /proc isn't mounted.
This commit is very similar to commit 3a1be725 ("linux: read free/total
memory from /proc/meminfo") from April 2019.
Fixes: https://github.com/nodejs/node/issues/33791
PR-URL: https://github.com/libuv/libuv/pull/2876
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Move common logic into a separate function that will be reused in a
follow-up commit. This commit also adds a minor correctness fix in
that the `read(2)` system call is now retried on `EINTR`.
PR-URL: https://github.com/libuv/libuv/pull/2876
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
It was reported that `getrlimit(RLIMIT_STACK)` fails on some aarch64
systems due to a glibc bug, where the getrlimit() system call wrapper
invokes the wrong system call.
Libuv could work around that by issuing a `prlimit(2)` system call
instead but since it can't assume that said system call is available
(it was added in Linux 2.6.36, libuv's baseline is 2.6.32) it seems
easier to just use the default 2M stack size when the call fails.
Fixes: https://github.com/nodejs/node/issues/33244
Refs: https://bugzilla.redhat.com/show_bug.cgi?id=1813089
PR-URL: https://github.com/libuv/libuv/pull/2848
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Libuv was copying `sizeof(struct sockaddr_storage)` bytes from source to
destination but the source was only `sizeof(struct sockaddr_in6)` bytes
big, or approximately 128 vs. 16 bytes.
Fixes: https://github.com/libuv/libuv/issues/2840
PR-URL: https://github.com/libuv/libuv/pull/2841
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Replace two biggish `struct sockaddr_storage` instances with a union
of `struct sockaddr_in` and `struct sockaddr_in6`, the latter being
the largest that function supports.
PR-URL: https://github.com/libuv/libuv/pull/2841
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
`uv_signal_init()` leads to the allocation of an IO watcher,
so if the loop initialization fails at a later point,
the `loop->watchers` list needs to be released.
PR-URL: https://github.com/libuv/libuv/pull/2837
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Exposes the original system error of the filesystem syscalls. Adds a new
uv_fs_get_system_error which returns orignal errno on Linux or
GetLastError on Windows.
Ref: https://github.com/libuv/libuv/issues/2348
PR-URL: https://github.com/libuv/libuv/pull/2810
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
I was getting some weird results when copying a 5GB file on Alpine
Linux on Raspberry Pi. Out of the 5GB only 1.1GB would get copied and
the process would finish without an error. After some digging I found
out that there's a problem that some data types have smaller number of
bytes on Alpine Linux on Raspberry Pi than on other platforms
apparently.
When getting the size of the file in bytes, stat holds the size in
off_t data type, like this:
struct stat {
...
off_t st_size; /* total size, in bytes */
...
};
In my case, off_t has 8 bytes which is enough to hold a value up to
some exabytes. The problem is that it gets assigned to bytes_to_send
variable, which is size_t. In my case, size_t is only 4 bytes, which
is only good for about 4GB. If the file is any larger, there's an
overflow when assigning it from stat to bytes_to_send. That's easy
to fix, I just changed the data type of bytes_to_send to off_t.
However there's more.
The other 2 variables - in_offset and bytes_written also have to be
able to hold the size of the entire file, therefore it makes sense to
change them to off_t as well.
The last problem is that bytes_to_send is passed down to
uv_fs_sendfile() which converts it to size_t again. I could go and
change the types everywhere across the whole codebase to off_t but
that could break other things, so it seams a bit too much. A much
better solution is to have a proxy variable bytes_chunk that is
size_t type and copy as much bytes as possible at a time that can
fit into size_t. That way it will work the same as before on other
platforms, where size_t is more than 4 bytes.
PR-URL: https://github.com/libuv/libuv/pull/2758
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Commit 3d713663 ("freebsd,linux: add recvmmsg() + sendmmsg() udp
implementation") forgot to zero some of the members of the msghdr
struct. It seems to work by accident, not by design.
PR-URL: https://github.com/libuv/libuv/pull/2819
Refs: https://github.com/libuv/libuv/pull/2818
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
The Windows documentation states these should not be possible
but several people have reported that they do in fact happen.
Try with a smallish stack-allocated buffer first and switch to
a heap-allocated buffer if the first one is too small.
Fixes: https://github.com/libuv/libuv/issues/2587
PR-URL: https://github.com/libuv/libuv/pull/2589
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Since Windows 10 1607 some WinApi functions no longer have a MAX_PATH
limit on the filenames length. This removes this hard-coded path length
limit from various places in libuv, switching to dynamically allocating
string buffers.
Fixes: https://github.com/libuv/libuv/issues/2331
PR-URL: https://github.com/libuv/libuv/pull/2788
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Commit 5736658b ("udp: add flag to enable recvmmsg(2) explicitly") added
the flag but didn't update the validation logic in src/win/udp.c.
This commit moves the validation logic to src/uv-common.c. The flag is
now accepted as a no-op on Windows.
Fixes: https://github.com/libuv/libuv/issues/2806
PR-URL: https://github.com/libuv/libuv/pull/2809
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Libuv already works without that API since commit 153ea114ff but still
had it as a hard requirement in the import table. This code uses the
`pGetQueuedCompletionStatusEx` function pointer instead, hence it also
works on systems that don't export `GetQueuedCompletionStatusEx`.
This simple fix improves compatibility of libuv with ReactOS and
Windows XP (latter using Vista+ compatibility libraries like
https://github.com/MyTDT-Mysoft/DllCompat)
PR-URL: https://github.com/libuv/libuv/pull/2800
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Make it possible to explicitly tell libuv to release any resources
it's still holding onto (memory, threads, file descriptors, etc.)
Before this commit, cleanup was performed in various destructors.
This commit centralizes the cleanup logic, enabling the addition of
`uv_library_shutdown()`, but maintains the current observable behavior
of cleaning up when libuv is unloaded by means of `dlclose(3)`.
Fixes: https://github.com/libuv/libuv/issues/2763
PR-URL: https://github.com/libuv/libuv/pull/2764
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
On Linux, cpu_times have been calculated differently to all other
platforms for a while. Other platforms (FreeBSD, Mac, Windows) are all
in milliseconds, but Linux has been returning values ten times larger.
libuv has not previously documented what unit cpu_times uses, even
though NodeJS did - as milliseconds.
Here we're both documenting that the cpu_times are indeed in
milliseconds, and fixing the inconsistency on Linux.
Fixes: https://github.com/libuv/libuv/issues/2773
PR-URL: https://github.com/libuv/libuv/pull/2796
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
`timer_less_than()` function is basically a comparator function
that returns true or false. In the end of the function we were
checking for the comparison of id, but the later if is redundant
as we are anyways in the end are returning `0`. That extra check
can thus be safely removed.
PR-URL: https://github.com/libuv/libuv/pull/2785
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
`required_vars_value_len` has a fixed number of elements. There is no
need to use alloca() to allocate it.
Refs: https://github.com/libuv/libuv/pull/2781
PR-URL: https://github.com/libuv/libuv/pull/2783
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
In commit 2475296c (build: make code compilable for iOS on Xcode,
2020-01-18, v1.35.0~47) we added a `defined(TARGET_OS_IPHONE)`
preprocessor condition, but `TARGET_OS_IPHONE` is always defined on
Apple to either 0 or 1. On 32-bit macOS architectures this
leads to an undefined symbol reference to `_close$NOCANCEL`.
Fix the preprocessor condition to use just `TARGET_OS_IPHONE`.
Refs: https://github.com/libuv/libuv/pull/2639
PR-URL: https://github.com/libuv/libuv/pull/2776
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Check the pointer to the allocated memory, not the pointer to the
pointer of the allocated memory. Previously, a failed allocation of
*envitems would lead to a NULL pointer dereference.
PR-URL: https://github.com/libuv/libuv/pull/2778
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
