It might happen that only using `WaitForSingleObject()` with timeout 0
could return WAIT_TIMEOUT as the process might not have been signaled
yet. To improve things, first use `GetExitCodeProcess()` and check
that `status` is not `STILL_ACTIVE`. Then, to cover for the case that the exit
code was actually `STILL_ACTIVE` use `WaitForSingleObject()`. This could
still be prone to the race condition but only for that case.
According to the documentation for Cygwin, the penultimate field
of /proc/pid/stat corresponds to the RSS, so the method is basically
the same as in the Linux version. The only difference is that getpagesize()
will return wincap.allocation_granularity(), but in this mapping, RSS is
calculated using wincap.page_size(), which can be accessed by sysinfo.mem_unit.
uv_available_parallelism does not handle container cpu limit
set by systems like Docker or Kubernetes. This patch fixes
this limitation by comparing the amount of available cpus
returned by syscall with the quota of cpus available defined
in the cgroup.
Fixes: https://github.com/libuv/libuv/issues/4146
It's been reported that creating many event loops introduces measurable
overhead now that libuv creates an sqpoll-enabled ring.
I don't really see any change in CPU time with or without this change
but deferring ring creation until it's actually used seems like a good
idea, and comes with no downsides that I can think of, so let's do it.
Fixes: https://github.com/libuv/libuv/issues/4308
Add a process options flag to enable the optional behavior. Most users
are likely recommended to set this flag by default, but it was deemed
potentially breaking to set it by default in libuv.
Co-authored-by: Kyle Edwards <kyle.edwards@kitware.com>
Since `io_uring` support was added, libuv's signal handler randomly
segfaults on ppc64 when interrupting `epoll_pwait`. Disable it
pending further investigation.
Issue: https://github.com/libuv/libuv/issues/4283
Solaris claimed it supported the TCP-Alives mechanism,
but TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT were not
available on Solaris until the latest version 11.4.
Therefore, we need to simulate the TCP-Alives mechanism on
other platforms via TCP_KEEPALIVE_THRESHOLD + TCP_KEEPALIVE_ABORT_THRESHOLD.
The `\0` character has no special significance in abstract sockets, so
the addrlen field in both `bind()` and `connect()` should take that into
account.
Calling `uv_timer_start(h, cb, 0, 0)` from a timer callback resulted in
the timer running immediately because it was inserted at the front of
the timer heap.
If the callback did that every time, libuv would effectively busy-loop
in `uv__run_timers()` and never make forward progress.
Work around that by collecting all expired timers into a queue and only
running their callback afterwards.
Fixes: https://github.com/libuv/libuv/issues/4245
Co-authored-by: Ben Noordhuis <info@bnoordhuis.nl>
Introduced long ago for old Linux/libc flavors libuv no longer supports.
We include <ifaddrs.h> unconditionally elsewhere so there is no point in
special-casing it here.
Fixes: https://github.com/libuv/libuv/issues/4242
Passing a socket name without a trailing nul byte to uv_pipe_bind2() or
(on Windows) uv_pipe_connect2() resulted in reading beyond the end of
the name buffer when copying or converting it.
Fix that by copying the socket name to temporary storage first and add
the trailing nul byte explicitly.
Add a check for embedded nul bytes in the socket name.
Fix a small memory leak in the Windows error path of uv_pipe_bind2().
There is no length at which this gets truncated on Windows. The
underlying file system will just not successfully connect to a longer
path (in WTF-16 characters), which will return an error asynchronously
with the existing API.
Refs: #4040
This was incorrectly dropped by #4030, where previously connecting to ""
might fail eventually, now instead it would return EINVAL and then fail
to initialize the struct or call the callback.
Add uv_thread_setpriority for setting priority for threads created by
uv_thread_create. Add uv_thread_getpriority for getting thread priority.
For Linux by default, if the scheduling policy is SCHED_OTHER and the
priority is 0, we need to set the nice value.
Fixes: https://github.com/libuv/libuv/issues/4051
Passing this to uv__is_ipv6_link_local() is causing a segmentation
fault. Note that the documentation for getifaddrs() explicitly states
that this value may be NULL.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
uv_os_uname() on Windows queries the registry value "HKEY_LOCAL_MACHINE\
SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName" to fill
uv_utsname_t. If calling application was compiled for x86 and run on a
x86_64 host, that query is redirected to "Computer\HKEY_LOCAL_MACHINE\
SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\ProductName"
instead.
For whatever reason, the value of 'ProductName' in the 32-bit registry
section on 64-bit Windows sometimes differs from the 64-bit equivalent
value and is inaccurate (e.g. containing the data
"Windows 10 Enterprise" while the 64-bit value accurately contains
"Windows 10 Pro").
Adds the 'KEY_WOW64_64KEY' security descriptor when opening the
appropriate registry key so that the value of ProductName is always
taken from the primary registry on 64-bit systems, regardless of
compiled architecture. The descriptor is safely ignored on 32-bit hosts.
As promised in #2970, this attempts to migrate code to a common set of
utilities in a common place in the code and use them everywhere. This
also exports the functionality, since the Windows API with
WideCharToMultiByte is fairly verbose relative to what libuv and
libuv's clients typically need, so it is useful not to require clients
to reimplement this conversion logic unnecessarily (and because Windows
is not 64-bit ready here, but this implementation is.)
The workaround for preadv/pwritev is needed only
for Solaris, not illumos, so avoid it on illumos.
Haiku R1/prebeta5 (and later) provide preadv and
pwritev, so only use workaround on lower versions.
Signed-off-by: Jeffrey H. Johnson <trnsz@pobox.com>
Implement in terms of pread/pwrite and only try to read/write the first
buffer. Callers are supposed to handle partial reads and libuv takes
care of partial writes.
(Our own fs_read_bufs test doesn't but that's fine because this commit
is a fix-up for unsupported platforms that aren't in our CI matrix.)
Fixes: https://github.com/libuv/libuv/issues/4176
Under heavy workloads pthread_cond_wait on macOS can return EINVAL while
all the input parameters are correct.
As it happens due to a syscall having an errno of EBUSY we can detect it
and work around it.
Fixes: https://github.com/libuv/libuv/issues/4165
We can use the |bufs| argument directly instead of always copying it
and sometimes heap-allocating it.
The same trick doesn't work for uv_fs_write() because the iterator
mutates the buffers in the list and that's visible to the caller.
Fixes: https://github.com/libuv/libuv/issues/4038
The previous implementation using si11v1cpcmodel did not return a valid
cpu model on z/OS. So use PCCA instead to correctly get the cpu model.
Co-authored-by: Wayne Zhang <shuowang.zhang@ibm.com>
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
Co-authored-by: Jonathan Lai <jonathan.lai@ibm.com>
Fixes: https://github.com/libuv/libuv/issues/4102
Make printing handles from gdb a little easier because it doesn't always
know how to locate the stdout or stderr globals from libc.
With this commit `call uv_print_all_handles(0, 0)` prints the handles
from the default loop to stderr.
XNU kernels anno ~2010 had a data corrruption bug where concurrent
write and pwrite calls sometimes resulted in blocks of zeroes being
written instead of the actual data.
Libuv works around that by serializing all writes with a process-wide
mutex, meaning oncurrent writes (for all files, not just single files)
have a concurrency of 1. Obviously that's not great for performance.
Modern day macOS no longer has this bug, so remove the workaround.
