Gyp will try a parallel build if it detect the system has >1 processor.
This functionality depends on the Python "multiprocessing" package. The
multiprocessing package on Windows requires that the top-level module is
importable as a module, see:
http://docs.python.org/2/library/multiprocessing.html#windows
This fixes issue #984.
Rewrite some of the macros in a way that:
a) makes them more likely to trigger compile-time errors if used
inappropriately, and
b) makes C++ compilers happy
The following now works though the used approach is nothing to write
home about:
$ ./gyp_uv -Duv_use_dtrace=true
# <output elided>
$ make -C out BUILDTYPE=Debug
# <output elided>
$ cd out/Debug && stap -L 'process("./run-tests").mark("*")'
process("./run-tests").mark("tick__start") $arg1:long $arg2:long
process("./run-tests").mark("tick__stop") $arg1:long $arg2:long
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.
Document the fact that the maximum path length for UNIX domain socket
paths is much less than _POSIX_PATH_MAX.
For most file systems, _POSIX_PATH_MAX is 1024 or 4096 bytes while
`sizeof(sockaddr_un.sun_path)` is typically between 92 and 108 bytes.
Cheking if the loop is alive is covered in the while loop afterwards.
Also, the stop flag will be cleared if necessary, which didn't happen
before this patch.
Mea culpa, the previous commit added another ERROR_FILENAME_EXCED_RANGE
case to the switch statement in uv_translate_sys_error(). This commit
fixes up the build error.
Make it possible to call uv_tty_reset_mode() from inside a signal
handler. The primary motivation is to make it possible to restore
the TTY from inside a SIGINT or SIGTERM signal handler.
Fixes#954.
Before this commit, multiple event loops raced with each other when a
SIGCHLD signal was received. More concretely, it was possible for
event loop A to consume waitpid() events that should have been
delivered to event loop B.
This commit addresses that by doing a linear scan over the list of
child processes. An O(n) scan is not terribly efficient but the
actual performance impact is not measurable in a benchmark that spawns
rounds of several thousands instances of /bin/false. For the time
being, this patch will suffice; we can always revisit it later.
Fixes#887.
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.
timer_again test makes an implicit assumption on the triggering
timing of a repeating timer. However, this assumption may be not
true on slower or virtualized architecture due to delay accumulation,
which may fail the test as show in [0].
This commit makes explicit checks conforming to the asserted behavior.
[0] http://ur1.ca/fr5c4
Signed-off-by: Luca Bruno <lucab@debian.org>
The loop_stop test makes an implicit assumption about the triggering
timing of a repeating trigger, which may not hold true on slower or
virtualized machines, thus failing the test as shown at [0] and
discussed at [1].
This commit relaxes the assumption, without mandating the exact number
of runs.
[0] http://ur1.ca/fr5bw
[1] https://groups.google.com/d/msg/libuv/5-fNIC7hIAo/yqznDmwHDAIJ
Signed-off-by: Luca Bruno <lucab@debian.org>
test-tty.c currently assumes that a TTY is available to the test runner,
and fails hard if not. This may not be true on some autobuilding
environment, making the build fail as shown in [0].
Instead, let's properly skip the test in such cases.
[0] http://ur1.ca/fr5bd
Signed-off-by: Luca Bruno <lucab@debian.org>
There're could be a situation, where one fsevents handle gets created
and another one is destroyed simultaneously. In such cases
`fsevent_need_reschedule` will be set to 1 twice and reset only once,
leaving handle destructor hanging in uv_sem_wait().
This commit reverts the following commits:
983fa68 darwin: fix 10.6 build error in fsevents.c
684e212 fsevents: use shared FSEventStream
ea4cb77 fsevents: FSEvents is most likely not thread-safe
9bae606 darwin: create fsevents thread on demand
Several people have reported stability issues on OS X 10.8 and bus
errors on the 10.9 developer preview.
See also joyent/node#6296 and joyent/node#6251.
The cleanup-after-error code path in uv_spawn() was closing file
descriptors indiscriminately. Only close file descriptors that we
created ourselves, not the ones that are passed in by the user.
Fixesjoyent/node#6297.
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.
It turns out that node.js relies on the blocking behavior of pipes in
some cases, notably when forking worker processes. Reopens#941.
This reverts commit 8fe4ca686b.
Don't rely on the caller to set the O_NONBLOCK flag on the file
descriptor.
Prevents sporadic stalls when the file descriptor is in blocking mode
and exactly as many bytes are read as there are available; in that case,
libuv will try to read again and block. Node.js was guilty of this.
Fixes#941.
