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.
Make sure this handle is functional. The Windows kernel seems to have a
bug that if the first use of AssignProcessToJobObject is for a Windows
Store program, subsequent attempts to use the handle with fail with
INVALID_PARAMETER (87). This is possilby because all uses of the handle
must be for the same Terminal Services session. We can ensure it is
tied to our current session now by adding ourself to it. We could
remove ourself afterwards, but there doesn't seem to be a reason to.
Secondly, we start the process suspended so that we can make sure we
added it to the job control object before it does anything itself (such
as launch more jobs or exit).
Fixes: https://github.com/JuliaLang/julia/issues/51461
If a signal was received but was not dispatched before fork then
caught_signals counter should be reset. Closing of signal pipe makes
impossible to receive the signal that was counted.
There is no need in this signal because it was sent to parent process
Fixes: https://github.com/libuv/libuv/issues/3483
Adjust include order to avoid redefining `CTL_CODE`, `FILE_READ_ACCESS`,
and `FILE_WRITE_ACCESS`. Without this, compilation shows:
```
...\um\winioctl.h(273): warning C4005: 'CTL_CODE': macro redefinition
...\src\win\winapi.h(4497): note: see previous definition of 'CTL_CODE'
...\um\winioctl.h(320): warning C4005: 'FILE_READ_ACCESS': macro redefinition
...\src\win\winapi.h(4488): note: see previous definition of 'FILE_READ_ACCESS'
...\um\winioctl.h(321): warning C4005: 'FILE_WRITE_ACCESS': macro redefinition
...\src\win\winapi.h(4492): note: see previous definition of 'FILE_WRITE_ACCESS'
```
Match the implementation for linux.c to kqueue.c in the code around the
calls to kevent and epoll.
In linux.c the code was made more DRY by moving the nfds check up
(including a comment of why it's possible) and combining two if checks
into one.
In kqueue.c the assert to check the timeout when nfds == 0 has been
moved to be called directly after the EINTR check. Since it should
always be true regardless.
Ref: https://github.com/libuv/libuv/pull/3893
Ref: https://github.com/nodejs/node/issues/48490
Link-local addresses (prefix fe80::/64) don't route unless you specify
the network interface to use so make libuv do that.
Fixes: https://github.com/nodejs/node/issues/48846
Work around a poorly understood bug in older kernels where closing a
file descriptor pointing to /foo/bar results in ETXTBSY errors when
trying to execve("/foo/bar") later on.
The bug seems to have been fixed somewhere between 5.15.85 and 5.15.90.
I couldn't pinpoint the responsible commit but good candidates are the
several data race fixes.
Interestingly, it seems to manifest only when running under Docker so
the possibility of a Docker bug can't be completely ruled out either.
This commit moves uv__kernel_version() from fs.c to linux.c because the
latter now uses it more than the former.
Fixes: https://github.com/nodejs/node/issues/48444
The initial run of timers shouldn't happen if uv_stop() has been run
before uv_run() was called, and for backwards compatibility they also
shouldn't run if they have been unref'd before calling uv_run().
Apple's documentation claims ru_maxrss is reported in kilobytes but the
XNU source code suggests the actual unit is bytes, like macOS.
Fixes: https://github.com/libuv/libuv/issues/4025
Recent versions of gcc have started emitting warnings about the liberal
type casting inside the QUEUE macros. Although the warnings are false
positives, let's use them as the impetus to switch to a type-safer and
arguably cleaner approach.
Fixes: https://github.com/libuv/libuv/issues/4019
