The compile-time detection check from commit 7b75935 ("kqueue: use
EVFILT_USER for async if available") was not being used, breaking
numerous operating systems. This commit hopefully unbreaks them.
Fixes; https://github.com/libuv/libuv/issues/4608
Signed-off-by: Jeffrey H. Johnson <trnsz@pobox.com>
Establishes a user event for kqueue to eliminate the overhead
of the pipe and the system call read(2) per wakeup event.
Relands commit 27134547ff using VSCode merge, since it shows the
conflict is just on the order of #ifdef calls.
Co-authored-by: Andy Pan <panjf2000@gmail.com>
This reverts commit e5cb1d3d3d.
Reason: bisecting says it breaks dnstap.
Also revert commit 27134547ff ("kqueue: use EVFILT_USER for async if
available") because otherwise the first commit doesn't revert cleanly,
with enough conflicts in src/unix/async.c that I'm not comfortable
fixing those up manually.
Fixes: https://github.com/libuv/libuv/issues/4584
Establishes a user event for kqueue to eliminate the overhead
of the pipe and the system call read(2) per wakeup event.
---------
Signed-off-by: Andy Pan <i@andypan.me>
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
Register the eventfd with EPOLLET to enable edge-triggered notification
where we're able to eliminate the overhead of reading the eventfd via
system call on each wakeup event.
When the eventfd counter reaches the maximum value of the unsigned 64-bit,
which may not happen for the entire lifetime of the process, we rewind the
counter and retry.
This optimization saves one system call on each event-loop wakeup,
eliminating the overhead of read(2) as well as the extra latency
for each epoll wakeup.
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
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
Equivalents of `pipe` and `socketpair` for cross-platform use.
PR-URL: https://github.com/libuv/libuv/pull/2953
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Assume the presence of the eventfd2() system call on Linux. It was added
in 2.6.27 and our baseline is 2.6.32.
PR-URL: https://github.com/libuv/libuv/pull/2665
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
After inspection of the code, it seems like there is a race window
between the cmpxchgi() and uv__async_send() calls.
If the event loop thread is already busy looping over the async handles,
it can invoke the callback - which in turn can close the handle - before
the other thread reaches the uv__async_send() call. That's bad because
it accesses the handle that at that point might not be valid anymore.
Fix that by introducing an ad hoc spinlock that blocks the event loop
thread until the sending thread is done. It's not pretty or elegant
but it fixes the immediate bug and appears to have no measurable
impact on the async handle benchmarks.
Fixes: https://github.com/libuv/libuv/issues/2226
PR-URL: https://github.com/libuv/libuv/pull/2231
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Using -errno, -E**, and -pthread_function() can be
error prone, and breaks compatibility with some operating
systems that already negate errno's (e.g. Haiku).
This commit adds a UV__ERR() macro that ensures libuv
errors are negative.
Fixes: https://github.com/libuv/help/issues/39
PR-URL: https://github.com/libuv/libuv/pull/1687
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Added the uv_loop_fork() API that must be called in a child process to
continue using an existing loop. Internally this calls a uv__io_fork
function for each supported platform, similar to the way
uv__platform_loop_init works.
After this call, existing and new IO, async and signal watchers will
contiue working as before on all platforms, as will the
threadpool (although any threads it was using are of course gone).
On Linux and BSDs that use kqueue, existing and new fsevent watchers
will also continue to work as expected. On OS X, though, directory
fsevents will not be able to use the optimized CoreFoundation path if
they had already been used in the parent process, instead falling back
to the kqueue path used on other BSDs.
Existing fsevent watchers will not function on AIX or SunOS. This
could be relatively easily fixed by someone with AIX knowledge in the
future, but SunOS will require some additional work to keep track if
the watchers.
A new test file, test/test-fork.c, was added to contain fork-related
tests to verify functionality in the child process.
PR-URL: https://github.com/libuv/libuv/pull/846
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Remove the unused `nevents` parameter from `uv__async_event()`
and remove the indirection of having a separate `uv__async`
type. There is only one instance per event loop these days.
This incidentally removes the `assert(n == sizeof(val))` in a
Linux-specific code path that some users seem to hit from time
to time. The cause is not well-understood and I've never been
able to reproduce it myself. Presumably libuv gets an EAGAIN
when trying to read from the eventfd but when and why that
happens is unclear.
Since the byte count is unused, removing the assert seems safe.
Worst case, libuv sometimes iterates over the async watcher list
when it doesn't have to.
Fixes: https://github.com/libuv/libuv/issues/1171
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Supersedes: https://github.com/libuv/libuv/pull/1214
Replace uses of QUEUE_FOREACH when the list can get modified while
iterating over it, in particular when a callback is made into the
user's code. This should fix a number of spurious failures that
people have been reporting.
PR-URL: https://github.com/libuv/libuv/pull/565
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
There's a data race in the consuming side of uv_async. The "pending"
flag could be trampled by producing thread causing an async send
event to be missed.
PR-URL: https://github.com/libuv/libuv/pull/189
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reopen one of the pipe descriptors as read/write through the procfs.
Allows us to close the original pipe file descriptors, saving a file
descriptor on kernels that don't support eventfd(2).
Ensure that close() system calls don't close stdio file descriptors
because that is almost never the intention.
This is also a partial workaround for a kernel bug that seems to affect
all Linux kernels when stdin is a pipe that gets closed: fd 0 keeps
signalling EPOLLHUP but a subsequent call to epoll_ctl(EPOLL_CTL_DEL)
fails with EBADF. See joyent/node#6271 for details and a test case.
This commit changes the libuv API to return error codes directly rather
than storing them in a loop-global field.
A code snippet like this one:
if (uv_foo(loop) < 0) {
uv_err_t err = uv_last_error(loop);
fprintf(stderr, "%s\n", uv_strerror(err));
}
Should be rewritten like this:
int err = uv_foo(loop);
if (err < 0)
fprintf(stderr, "%s\n", uv_strerror(err));
The rationale for this change is that it should make creating bindings
for other languages a lot easier: dealing with struct return values is
painful with most FFIs and often downright buggy.
`#if FOO` (where FOO is undefined) is a legal construct in C89 and C99
but gcc, clang and sparse complain loudly about it at higher warning
levels.
Squelch those warnings. Makes the code more consistent as well.
kqueue(2) on osx doesn't work (emits EINVAL error) with specific fds
(i.e. /dev/tty, /dev/null, etc). When given such descriptors - start
select(2) watcher thread that will emit io events.
This reverts commit 209abbab27.
Fixes the following SIGSEGV:
(gdb) f 1
#1 0x00007fc084683aec in uv__async_io (loop=0x7fc0848e0b40,
handle=0x7fc0848e0c78, events=1) at src/unix/async.c:175
175 ASYNC_CB(h)
(gdb) list
170
171 /* If we need to sweep all handles anyway - skip this loop */
172 if (!loop->async_sweep_needed) {
173 for (i = 0; i < end; i += sizeof(h)) {
174 h = *((uv_async_t**) (buf + i));
175 ASYNC_CB(h)
176 }
177 }
178
179 bytes -= end;
(gdb) print *h
$1 = {close_cb = 0x184e1b0, data = 0x18d9520, loop = 0x7fc0848e0b40,
type = 49, handle_queue = {prev = 0x18dae10, next = 0x7860c0}, flags = 32,
next_closing = 0x1863b40, pending = 0, async_cb = 0x31,
queue = {prev = 0x18dae50, next = 0x7860c0}}
(gdb)
It looks like the async handle gets closed or otherwise becomes invalid before
the sweep is executed.
Fixes#603.
Include missing <string.h> header. Fixes the following compiler warning:
src/unix/async.c:182:7: warning: implicit declaration of
function ‘memmove’ [-Wimplicit-function-declaration]
Fixes the following gcc 4.7+ warning:
../src/unix/internal.h:105:13: warning: always_inline function might not be
inlinable [-Wattributes]
gcc wants the always_inline function to be annotated with the 'inline' keyword
which we can't do because we compile in C89 mode.
Using __inline is not an option because that makes clang generate warnings when
-Wlanguage-extension-token is enabled.
Therefore, remove the always_inline attribute altogether and hope that the
compiler is smart enough to inline the functions.
uv_async_send would always return 1 when non-gcc compilers were used.
When uv_async_send returns 1 no attempt is made to make port_getn
return, so in this situation uv_async_send didn't wake up the event
loop.
Use atomic compare-and-swap to detect if we've been preempted by another thread
and therefore can avoid making the expensive write() syscall.
Speeds up the heavily contended case by about 1-2% and has little if any impact
on the non-contended case. I wasn't able to measure the difference at any rate.
This commit changes how the event loop determines if it needs to stay alive.
Previously, an internal counter was increased whenever a handle got created
and decreased again when the handle was closed.
While conceptually simple, it turned out hard to work with: you often want
to keep the event loop alive only if the handle is actually doing something.
Stopped or inactive handles were a frequent source of hanging event loops.
That's why this commit changes the reference counting scheme to a model where
a handle only references the event loop when it's active. 'Active' means
different things for different handle types, e.g.:
* timers: ticking
* sockets: reading, writing or listening
* processes: always active (for now, subject to change)
* idle, check, prepare: only active when started
This commit also changes how the uv_ref() and uv_unref() functions work: they
now operate on the level of individual handles, not the whole event loop.
The Windows implementation was done by Bert Belder.
