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).
- 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
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
Dynamic loading with musl only works with libc.so because it is
is implemented in musl's dynamic linker, not in libc proper.
libc.a contains just a stub dlopen() that always fails with a "Dynamic
loading not supported" error message. Update the test to handle that.
Fix: https://github.com/libuv/libuv/issues/3706
Some setsockopt() implememantations may return with errno of EINVAL
when the socket has been shut down already, as documented in the
Open Group Specifications Issue 7, 2018.
When this happens, reset errno and continue to mark the socket closed
and handle any callback.
Previously, Windows would always defer event processing to the loop
after they were received. This could cause confusion for users who were
using prepare and idle callbacks, as seen from this bug in nodejs[^1] and
this discussion in libuv[^2], and even some discrepancies in the libuv
tests too[^3].
[^1]: https://github.com/nodejs/node/pull/42340
[^2]: https://github.com/libuv/libuv/discussions/3550
[^3]: See change to test-spawn.c in this PR
So rather than declare those usages to be wrong, we change libuv to meet
those users expectations.
Replaces: https://github.com/libuv/libuv/pull/3585
This test has always been disabled for the 10 years of its existence and
there are other tests that exercise "what happens when" event ordering.
Fixes: https://github.com/libuv/libuv/issues/3618
macOS 10.15 has a bug where configuring the working directory with
posix_spawn_file_actions_addchdir_np() makes posix_spawnp() fail with
ENOENT even though the executable is spawned successfully.
Co-authored-by: Ben Noordhuis <info@bnoordhuis.nl>
On illumos and Solaris, fs events are implemented with
PORT_SOURCE_FILE type event ports. These are one-shot so
need re-arming each time they fire. Once they are armed
and an event occurs, the kernel removes them from the current
cache list and puts them on an event queue to be read by
the application.
There's a window in closing one of these ports when it could
have triggered and be pending delivery. In that case, the
attempt to disarm (dissociate) the event will fail with ENOENT
but libuv still goes ahead and closes down the handle. In
particular, the close callback (uv_close() argument) will be
called but then the event will subsequently be delivered if
the loop is still active; this should not happen.
This commit adds the support for a custom strtok implementation, which
is reentrant. On some systems strtok_r or strstep is available for that
purpose; however, since these are an extension, it is difficult to
control if it will be available on every supported system.
Replacement for the usage pattern where people use uv_cpu_info() as an
imperfect heuristic for determining the amount of parallelism that is
available to their programs.
Fixes#3493.
Added in https://github.com/libuv/libuv/pull/742, these values are
typically defined as unsigned (since Linux 2.4). Only -1 is special,
representing an invalid id (e.g. see setreuid).
The read callback failed to handle the `nread == 0` case, which is rare
to non-existent on the systems we test on but apparently happens often
enough on Solaris on SPARC to draw attention.
Fixes#3469.
Take into account that the data may not be already available in the
socket causing the `recvmsg()` / `recvmmsg()` calls to return `EAGAIN`
or `EWOULDBLOCK`.
Fixes: https://github.com/libuv/libuv/issues/3479
- Fixes the declaration of the benchmark in benchmark-list.h (it was not
previously runnable at all)
- Fixes the benchmark itself hanging infinitely because the data was
being dropped via ICMP Destination Unreachable errors (meaning nread
was always zero in pinger_read_cb)
+ The data getting lost was fixed by binding the udp socket
- Properly checks for UV_UDP_MMSG_CHUNK, just as an example of what
should generally be done (buf_free is actually a no-op as the buf is
allocated on the stack)
The test is very flaky, both on the CI and on people's local machines.
I spent some time trying to fix it but its design is fairly questionable
and it fails to test what it should more often than not because on fast
machines no queueing of data takes place.
Fixes#2307.
Disable `atime` testing for symlink as this test
is dependant on a race condition on some OSes
(Linux is one) as `lstat` updates the `atime`.
As both `mtime` and `atime` are set by the same
syscall, barring an eventual kernel bug, this
test does not omit any error case.
This adds a workaround for an xnu kernel bug that sometimes results in
SIGCHLD not being delivered. The workaround is to use kevent to listen
for EVFILT_PROC/NOTE_EXIT events instead of relying on SIGCHLD on *BSD.
Apple rdar: FB9529664
Refs: https://github.com/libuv/libuv/pull/3257
uv_thread_create_ex() lets you set a stack size that is smaller than is
safe. It enforces a lower bound of PTHREAD_STACK_MIN (when that constant
is defined) but with musl libc that's still too small to receive signals
on.
Put the lower bound at 8192 or PTHREAD_STACK_MIN, whichever is greater.
The same restriction was already in place for the _default_ stack size.
The maximum numbers receivable by the recvmmsg call is defined in
src/unix/udp.c as UV__MMSG_MAXWIDTH with the current value being 20.
Align the size of the receive buffer in the mmsg test to receive the
maximum number of UDP packets in the test.
In particular, previously the main thread would have an id of NULL,
which was then not valid to use with any other API that expected a
uv_thread_t handle.
On some streams (notably TTYs), it is permitted to continue reading
after getting EOF. So still stop reading on EOF, but allow the user to
reset the stream and try to read again (which may just get EOF).
This relaxes the constraint added in ce15b8405e.
Refs: https://github.com/libuv/libuv/pull/3006
Oracle Developer Studio requires public functions to be
defined as "__global" when "-fvisibility=hidden" used as
added by [#3005](https://github.com/libuv/libuv/pull/3005).
For documentation on `__global` see Reducing Symbol Scope in
Oracle Developer Studio C/C++ guide
https://www.oracle.com/solaris/technologies/symbol-scope.html.
fs_utime_round test failed as timespec.tv_nsec conversion to
double resulted in negative number. Skip this test for
__SPRO_C builds.
Note that it was necessary to have C99 language features
enabled with Studio compiler (-xc99=all) as version v1.41.0
has other commits that have used C99 features.
Tested with:
- cc: Studio 12.6 Sun C 5.15 SunOS_sparc 152881-05 2019/10/30
- gcc (GCC) 11.2.0
Refs: https://github.com/libuv/libuv/pull/3364
Oracle Solaris linker visibility support. Option "-fvisibility=hidden"
requires public functions to be defined as "__global".
fs_utime_round test failed as timespec.tv_nsec conversion to double
resulted in negative number. Skipped this test.
Note that it was necessary to compile with C99 language features.
Just like the Unix counterpart, uv_fs_read() and uv_fs_write() should
throw an EBADF instead of throwing an EPERM when the passed fd has not
been opened with the right flags.
Signed-off-by: Darshan Sen <darshan.sen@postman.com>
Previously they were just being run incorrectly, but nothing wrong with
the test itself. We were also interpreting an ASAN failure as TEST_SKIP,
so test failures would not actually be reported as CI failures.
Fix a logic error where calling uv_fs_event_stop() from the event
callback tripped on a `handle->dir_handle != INVALID_HANDLE_VALUE`
assert in uv_fs_event_queue_readdirchanges().
Fixes: https://github.com/libuv/libuv/issues/3258
PR-URL: https://github.com/libuv/libuv/pull/3259
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
