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>
Old 32 bits kernels (native and compat) have a bug where timeouts larger
than (LONG_MAX / CONFIG_HZ) milliseconds are treated as infinite.
Work around that by capping the timeout and polling again if necessary.
PR-URL: https://github.com/libuv/libuv/pull/354
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
arm64 doesn't have a epoll_wait() system call but a logic error stopped
libuv from falling back to epoll_pwait().
This bug was introduced in commit 67bb2b5 ("linux: fix epoll_pwait()
regression with < 2.6.19") which sadly exchanged one regression for
another.
PR-URL: https://github.com/libuv/libuv/pull/308
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>
Work around a bug in kernels 3.10 to 3.19 where passing a struct that
has the EPOLLWAKEUP flag set generates spurious syslog audit warnings.
A bad check makes the kernel read the events field when it should not
and complain when the process lacks the CAP_BLOCK_SUSPEND capability.
PR-URL: https://github.com/libuv/libuv/pull/245
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Linux before kernel 2.6.19 does not support epoll_pwait(). Due to a
logic error in commit 2daf944 ("unix: add flag for blocking SIGPROF
during poll"), the fallback path for ENOSYS was not taken.
This commit also adds epoll_pwait() emulation using pthread_sigmask().
The block/unblock operations are not atomic but that is fine for our
particular use case, to wit, sleep through SIGPROF signals.
PR-URL: https://github.com/libuv/libuv/pull/162
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv_exepath() should write as much as possible to the output buffer.
In the case of size=1, skip the call to readlink() because it will
fail with EINVAL; just write the terminating zero byte.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Make the behavior of a call to uv_exepath() with a size argument of zero
consistent with the Windows implementation where it returns UV_EINVAL.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Revisit the fix from commit b705b53. The problem with using sigset_t
and _NSIG is that the size of sigset_t and the value of _NSIG depend
on what headers libuv picks up first, <signal.h> or <asm/signal.h>.
With the former, sizeof(sigset_t) = 128; with the latter, it's 8.
Simply sidestep the issue by calculating the signal mask as a 64 bits
integer, without using sigset_t or _NSIG.
PR-URL: https://github.com/libuv/libuv/pull/83
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This was pointed out as possible undefined allocation of 0 bytes by
clang-analyzer. `malloc` of 0 bytes can return either `NULL` or a
valid pointer which can't be dereferenced. On systems which return
`NULL`, we would consider it a `malloc` error and return an `ENOMEM` to
the caller.
PR-URL: https://github.com/libuv/libuv/pull/13
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>
It seems that epoll_wait is implemented in glibc in terms of epoll_pwait and
new architectures (like arm64) do not implement the epoll_wait syscall at all.
So if epoll_wait errors with ENOSYS, just call epoll_pwait.
This is a backport of 861de3d71d for v0.10
branch.
It seems that epoll_wait is implemented in glibc in terms of epoll_pwait and
new architectures (like arm64) do not implement the epoll_wait syscall at all.
So if epoll_wait errors with ENOSYS, just call epoll_pwait.
If the same file description is open in two different processes, then
closing the file descriptor is not sufficient to deregister it from the
epoll instance (as described in epoll(7)), resulting in spurious events
that cause the event loop to spin repeatedly. So always explicitly
deregister it.
Fixes#1099.
Conflicts:
test/test-spawn.c
If the same file description is open in two different processes, then
closing the file descriptor is not sufficient to deregister it from the
epoll instance (as described in epoll(7)), resulting in spurious events
that cause the event loop to spin repeatedly. So always explicitly
deregister it.
Fixes#1099.
When building using gyp and BUILDTYPE=Release using clang 3.4 received
this warning:
../src/unix/linux-core.c:640:34: warning: variable 'n' is uninitialized
for (len = sizeof("cpu0"); n /= 10; len++);
^
Initializing n = 0 silences this build warning.
CPU entries in /proc/stat are not guaranteed to be monotonically
increasing, asserting on this assumption can break in cases such
as the UltraSparc II machine shown in #1080.
Signed-off-by: Luca Bruno <lucab@debian.org>
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
Work around an epoll quirk where it sometimes reports just the EPOLLERR
or EPOLLHUP event. In order to force the event loop to move forward,
we merge in the read/write events that the watcher is interested in;
uv__read() and uv__write() will then deal with the error or hangup in
the usual fashion.
Fixes#982.
This is a back-port of commit 24bfef2 from the master branch.
Work around an epoll quirk where it sometimes reports just the EPOLLERR
or EPOLLHUP event. In order to force the event loop to move forward,
we merge in the read/write events that the watcher is interested in;
uv__read() and uv__write() will then deal with the error or hangup in
the usual fashion.
Fixes#982.
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.
On some systems, clock_gettime(CLOCK_MONOTONIC) is only serviced from
the vDSO when the __vdso_clock_gettime() wrapper is confident enough
that the vDSO timestamp is highly accurate. When in doubt, it falls
back to making a traditional SYS_clock_gettime system call with all
the overhead that entails.
While a commendable approach, it's overkill for our purposes because we
don't usually need high precision time. That's why this commit switches
to CLOCK_MONOTONIC_COARSE for low-precision timekeeping, provided said
clock has at least a one millisecond resolution.
This change should eliminate the system call on almost all systems,
including virtualized ones, provided the kernel is >= 2.6.32 and glibc
is new enough to find and parse the vDSO.
Before this commit, uv_uptime() returned the nanoseconds as the
fractional part of the uptime. It's a bit inconsistent with the
output on other platforms because those only return whole seconds
(with the possible exception of Windows.)
This commit changes linux-core.c to only return whole seconds.
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.
Tested most of my compilation in the previous patch on NodeJS
and extracted the patches from there. This patch ensures libuv
will be capable of building standalone as well, both with gyp
and Makefiles.
Build documentation was added to the README.md file.
Some tests are failing, and I have not heavily investigated
the reasons. The failures are generally on errors, and are
likely related to differences between fully POSIX-compatible
systems and android.
