The worker pool calls all callbacks locally within the queue. So the
value of nevents doesn't properly reflect that case. Increase the number
of events directly from the worker pool's callback to correct this.
In order to properly determine if the events_waiting counter needs to be
incremented, store the timeout value at the time the event provider was
called.
Since we are emulating this event, but are not using the pending_queue,
we need to make sure it is accounted for properly. Also DRY some of the
reset_timeout code here.
This was observed to cause a hang in certain rare cases, particularly on
M1 machines.
Do a bit of code cleanup too, since we do not need to initialize the
internal signal handling pipe if it will not be used.
The following metrics are now always recorded and available via the new
uv_metrics_info() API.
* loop_count: Number of event loop iterations.
* events: Total number of events processed by the event handler.
* events_waiting: Total number of events waiting in the event queue when
the event provider request was made.
Benchmarking has shown no noticeable impact recording these metrics.
PR-URL: https://github.com/libuv/libuv/pull/3749
- 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
Remove the TODO that says to batch up kevent(EV_DELETE) system calls.
It's unduly complicated in case of errors.
If you pass an out array to kevent(), it will store error records that
tell you which file descriptor caused the error but it also stores new
events in the array, complicating state management.
If you don't pass an out array, it simply doesn't tell you anything
except that _something_ failed. Optimistically trying batch deletion
and falling back to one-by-one deletion is probably possible but is
something of a deoptimization and also feels somewhat dangerous.
macOS has a mostly-undocumented kevent_qos() system call that accepts a
KEVENT_FLAG_ERROR_EVENTS flag that fixes the first problem but that of
course isn't portable.
Long story short, it seems like too much hassle for too little payoff.
Libuv has been doing one-by-one deletion for over a decade now and no
one complained about performance so far so let's just stick with that.
After analysis of many real-world programs I've come to conclude that
accepting in a loop is nearly always suboptimal.
1. 99.9% of the time the second accept() call fails with EAGAIN, meaning
there are no additional connections to accept. Not super expensive
in isolation but it adds up.
2. When there are more connections to accept but the listen socket is
shared between multiple processes (ex. the Node.js cluster module),
libuv's greedy behavior necessitated the UV_TCP_SINGLE_ACCEPT hack
to slow it down in order to give other processes a chance.
Accepting a single connection and relying on level-triggered polling to
get notified on the next incoming connection both simplifies the code
and optimizes for the common case.
On NetBSD with libuv 1.44.1 we see that cmake occasionally hangs
waiting for a child process to exit, with libuv waiting forever for
`kevent` to deliver more events that never come. The child process has
already exited and is waiting to be collected with `waitpid`.
The hang occurs when the batch of events returned by one call to
`kevent` contains both a EVFILT_READ event for an fd and a later
EVFILT_PROC record for the PID with the same value as the earlier fd.
What happens is that `uv__platform_invalidate_fd` is called to
invalidate events later in the same batch for the fd, but
`uv__platform_invalidate_fd` invalidates the later EVFILT_PROC event
too because it sees the same "ident" value and does not check the
"filter" value to differentiate "ident" values that refer to fds vs.
"ident" values that refer to PIDs.
Add a check for the "filter" value to avoid confusing these two
different kinds of event "ident" values.
Bug #3504 seems to affect more platforms than just OpenBSD. As this
seems to be a race condition in these kernels, we do not want to fail
because of it. Instead, we remove the WNOHANG flag from waitpid, and
track exactly which processes have exited. Should also be a slight speed
improvement for excessively large numbers of live children.
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
The combination EVFILT_WRITE+EV_EOF is valid and indicates that the
reader has disconnected (called `shutdown(SHUT_RD)`). Probably very rare
in practice, but this seems more correct.
Issue noticed (for UV_DISCONNECT clients of uv_poll), while doing
research for https://github.com/libuv/libuv/pull/3250.
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>
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>
Newer macOS systems (10.7+) use fsevents() for the fs_event backend,
but older macOS systems don't have full functionality for this in
the macOS fsevents() API. Fall back to kqueue for these systems.
PR-URL: https://github.com/libuv/libuv/pull/2290
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Close the watched file's file descriptor when initialization fails due
to out-of-memory conditions.
PR-URL: https://github.com/libuv/libuv/pull/2197
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Add a missing check in uv__io_close() where it called
uv__platform_invalidate_fd() without checking that the
watcher actually has a valid file descriptor assigned.
Fixes: https://github.com/libuv/libuv/issues/2181
PR-URL: https://github.com/libuv/libuv/pull/2182
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
In the original PR, the ifdef conditional was reversed,
leading to the old code-path still being used.
This also reduces some of the redundancy in the conditional checks,
by factoring out the common test.
And fixes a divergence in functionality kFSEventsRenamed =>
kFSEventStreamEventFlagItemRenamed
And actually includes the part of the original PR to kqueue that enabled
watching files with fsevents!
Fixes: https://github.com/libuv/libuv/pull/387
PR-URL: https://github.com/libuv/libuv/pull/2082
Refs: https://github.com/libuv/libuv/pull/1572
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Back in the day I wrote comments in a really unusual way. Nowadays it
makes my eyes bleed, and clang-format doesn't know how to deal with it.
PR-URL: https://github.com/libuv/libuv/pull/1853
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.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>
The kqueue documentation states that the file descriptor is not
inherited by the child process. Hence, do not close it in uv_loop_fork
to avoid tampering with a possibly valid file descriptor already opened
by the child process.
PR-URL: https://github.com/libuv/libuv/pull/1583
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
The uv__has_forked_with_cfrunloop local variable is unused on
BSDs and causes compilation warnings. Observed on NetBSD/amd64
8.99.2 with GCC 5.4.0.
PR-URL: https://github.com/libuv/libuv/pull/1529
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Out-of-band TCP messages are used for TCP data
transmission outside (outband) the inbound TCP
data. These packets are sent with an
"urgent pointer", but previously discarded.
Additionally, when using (e)poll a POLLPRI is
triggered when an interrupt signal is received
on GPIO capable systems such as the Raspberry Pi.
PR-URL: https://github.com/libuv/libuv/pull/1040
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>
It was reported that some node.js tests fail on AIX because the exit
event sometimes comes before the final stdio output of a child process.
Work around that by deferring the signal watcher that is used for
process management until after the dispatch of regular i/o watchers.
Fixes: https://github.com/libuv/libuv/issues/610
PR-URL: https://github.com/libuv/libuv/pull/611
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Libuv would abort() when trying to watch a file descriptor that is
not compatible with epoll-style polling; file descriptors referring
to on-disk files fall into this category.
File descriptors that libuv creates itself are not an issue but
external ones that come in through the uv_poll_init() API are.
Make uv_poll_init() check whether the file descriptor is accepted by
the underlying system call and return an error when it's not.
Fixes: https://github.com/libuv/libuv/issues/658
PR-URL: https://github.com/libuv/libuv/pull/659
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Add new UV__POLLRDHUP event to be emitted when EPOLLRDHUP(in Linux) or
EV_EOF(in BSD / OSX) is detected and only if UV_READABLE is set.
When a read returns ECONNRESET after a UV__POLLRDHUP event, emit EOF instead
of the error.
Add tcp-squelch-connreset test. Not to be run on Windows as it returns
ECONNRESET error.
Fixes in test-poll and test-tcp-open so they pass after these changes.
PR-URL: https://github.com/libuv/libuv/pull/403
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
With uv_replace_allocator, it's possible to override the default
memory allocator's malloc and free calls with functions of the user's
choosing. This allows libuv to interoperate with projects requiring a
custom memory allocator.
Internally, all calls to malloc and free have been replaced with
uv__malloc and uv__free, respectively. The uv__malloc and uv__free
functions call malloc and free unless they have been overridden by a
previous call to uv_replace_allocator.
As part of this change, the special aligned memory allocations
performed in src/win/fs-event.c have been replaced with standard
allocations. The 4-byte alignment being requested in this file was
unnecessary, since standard allocators already guarantee at least an
8-byte alignment.
PR-URL: https://github.com/libuv/libuv/pull/231
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Add a per-event loop flag for blocking SIGPROF signals when polling for
events.
The motivation for this addition is to reduce the number of wakeups and
subsequent clock_gettime() system calls when using a sampling profiler.
On Linux, this switches from epoll_wait() to epoll_pwait() when enabled.
Other platforms bracket the poll syscall with pthread_sigmask() calls.
Refs strongloop/strong-agent#3 and strongloop-internal/scrum-cs#37.
PR-URL: https://github.com/libuv/libuv/pull/15
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Invalidate file descriptor when closing `uv_fs_event_t` handle. Note
that `uv__io_stop` is just removing `fd` from `loop->watchers` and not
actually invalidating all consequent events in a `kevent()` results.
fixjoyent/node#1101
In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it
appearded that all segfaults happened at the same instruction, and upon
translating the assembly back to the source, I found that an array could
be indexed with a -1 index before the index was checked to be not -1.
As concrete evidence, here is the situation that I found caused the
segfault. The instruction in question along with the relevant register
values was:
mov (%r8,%r15,8),%r12
r8 = 0x7fb0ba800000
r15 = 0xffffffffffffffff
r8 + r15 * 8 == 0x7fb0ba7ffff8
It appears that the base of loop->watchers was page aligned, and by
going back one word I guess that the page wasn't mapped, causing our
segfaults.
In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it
appearded that all segfaults happened at the same instruction, and upon
translating the assembly back to the source, I found that an array could
be indexed with a -1 index before the index was checked to be not -1.
As concrete evidence, here is the situation that I found caused the
segfault. The instruction in question along with the relevant register
values was:
mov (%r8,%r15,8),%r12
r8 = 0x7fb0ba800000
r15 = 0xffffffffffffffff
r8 + r15 * 8 == 0x7fb0ba7ffff8
It appears that the base of loop->watchers was page aligned, and by
going back one word I guess that the page wasn't mapped, causing our
segfaults.
When fd is closed and new one (with the same number) is opened inside
kqueue/epoll/port loop's callback - stale events might invoke callbacks
on wrong watchers.
Check if watcher was changed after invocation and invalidate all events
with the same fd.
fix#826
Drops commit 3780e12 ("fsevents: support japaneese characters in path")
for being quite inapplicable to the master branch. Will be reworked
and applied in a follow-up commit.
Conflicts:
README.md
build.mk
src/unix/fsevents.c
src/unix/udp.c
Watchers could be stopped between two `kevent()`/`epoll_wait()` calls
(which may happen in the same loop in `uv__io_poll()`), in such cases
`watcher->events` could be stale and won't be updated to
`watcher->pevents`.
Try to use and rely on `watcher->pevents` instead of blindly expecting
`watcher->events` to be always correct.
