Fixes a bug where timers expire prematurely when the following
conditions hold:
a) libuv first spends some time blocked in the platform poll function
b) a callback then calls uv_timer_start()
Cause: uv_timer_start() uses an out-of-date loop->time in its
'when should the timer callback run?' calculations.
Solution: Update loop->time before invoking any callbacks.
Fixes#678.
This commit renames the various uv_hrtime() implementations to uv__hrtime().
Libuv uses the high-res timer internally in performance-critical code paths.
Calling the non-public version avoids going through the PLT when libuv is
compiled as a shared object.
The exported uv_hrtime() now has a single definition in src/unix/core.c that
calls uv__hrtime().
A future optimization is to lift the uv__hrtime() declarations into header
files so they can be inlined at the call sites. Then again, linking with -flto
should accomplish the same thing.
Makes the new process name visible in both `ps` and `ps a`, with the caveat
that `ps` will only print the first 16 characters.
Before this commit, `ps` kept reporting the old process name.
Obtain the CPU frequency from /proc/cpuinfo because there may not be any
cpufreq info available in /sys. This also means that the reported CPU speed
from now on is the *maximum* speed, not the *actual* speed the CPU runs at.
This change only applies to x86 because ARM and MIPS don't report that
information in /proc/cpuinfo.
Fixes#588.
Free the memory that is used to store the new argv and envp. It's not strictly
necessary (the OS is going to reclaim the memory anyway) but it makes the output
from valgrind a lot less noisy.
Make uv_cpu_info() understand the ARM and MIPS versions of /proc/cpuinfo,
it only knew how to deal with the x86 version
This commit also fixes a buglet where uv_cpu_info() reported the maximum CPU
frequency instead of the actual CPU frequency. That is, before this commit
`out/Debug/run-tests platform_output | grep speed | sort | uniq -c` on my
system always reported:
8 speed: 3400
Now it reports (for example):
2 speed: 3400
6 speed: 1600
In other words, two CPUs are running at full speed while the others have been
scaled back because they're mostly idle.
This is a back-port of commit 54bfb66 from the master branch.
Fixes#526.
Make uv_cpu_info() understand the ARM and MIPS versions of /proc/cpuinfo,
it only knew how to deal with the x86 version
This commit also fixes a buglet where uv_cpu_info() reported the maximum CPU
frequency instead of the actual CPU frequency. That is, before this commit
`out/Debug/run-tests platform_output | grep speed | sort | uniq -c` on my
system always reported:
8 speed: 3400
Now it reports (for example):
2 speed: 3400
6 speed: 1600
In other words, two CPUs are running at full speed while the others have been
scaled back because they're mostly idle.
Fixes#526.
It's making node.js crash when run as root. Backtrace:
(gdb) bt
#0 0x00007fff856e3ff9 in __findenv ()
#1 0x00007fff856e404c in getenv ()
#2 0x000000010004c850 in loop_init (loop=0x10045a792, flags=8) at ev.c:1707
#3 0x000000010004cb3b in ev_backend [inlined] () at /Users/tjfontaine/Development/node/deps/uv/src/unix/ev/ev.c:2090
#4 0x000000010004cb3b in ev_default_loop (flags=1606417108) at ev.c:2092
#5 0x000000010004e5c6 in uv__loop_init (loop=0x10066e330, default_loop=1) at loop.c:52
#6 0x0000000100044367 in uv_default_loop () at core.c:196
#7 0x0000000100004625 in node::Init (argc=1606417456, argv=0x100b0f490) at node.cc:2761
#8 0x000000010000797d in node::Start (argc=1606417600, argv=0x0) at node.cc:2888
#9 0x0000000100000ca4 in start ()
This reverts commits:
b49d6f7 unix: fix uv_set_process_title()
a9f6f06 unix: fix format string vulnerability in freebsd.c
a87abc7 unix: avoid buffer overflow in proctitle.c
dc97d44 unix: move uv_set_process_title() to proctitle.c
Use hijacking argv array to change process' title. It seems to be working fine
on almost every platform (at least it should not break anything as it's used in
nginx in a similar way).
This is a back-port of commit e1320757 from the master branch.
Newer versions of gyp do not support files with the same basenames (example:
core.c and linux/core.c).
The nominal reason is consistency across build systems. Apparently, msbuild
doesn't support it either.
Somewhere, someplace, baby Jesus cries sad little tears...
Fixes#464.
Newer versions of gyp do not support files with the same basenames (example:
core.c and linux/core.c).
The nominal reason is consistency across build systems. Apparently, msbuild
doesn't support it either.
Somewhere, someplace, baby Jesus cries sad little tears...
Fixes#464.
