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.
This is a back-port of commit 775064a from the master branch.
* Use link_settings instead of direct_dependent_settings.
* Fix typo: s/ldlags/ldflags/
Pointed out by a certain R.L. Dahl of San Francisco, CA.
Fixes#618.
Currently, `uv_spawn` will set `environ` to the value of `options.env`, even if
`options.env` is `NULL`. This results in child processes for whom `environ ==
NULL`, which can cause a variety of unexpected issues.
This is a back-port of commit 1d85815 from the master branch.
Guard against the possibility that the queue is emptied while we're iterating
over it. Simple test case:
#include "ngx-queue.h"
#include <assert.h>
int main(void) {
ngx_queue_t h;
ngx_queue_t v[2];
ngx_queue_t* q;
unsigned n = 0;
ngx_queue_init(&h);
ngx_queue_insert_tail(&h, v + 0);
ngx_queue_insert_tail(&h, v + 1);
ngx_queue_foreach(q, &h) {
ngx_queue_remove(v + 0);
ngx_queue_remove(v + 1);
n++;
}
assert(n == 1); // *not* 2
return 0;
}
Fixes#605.
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.
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.
Don't spin in epoll_wait() / kevent() / port_getn() / etc. when we can't
accept() a new connection due to having reached the file descriptor limit.
Pass the error to the connection_cb and let the libuv user deal with it.
Some memory was leaked when the uv_udp_t handle was closed when there were
in-flight send requests with a heap allocated buffer list.
That doesn't happen much in practice. In the common case (writing < 5 buffers),
the buffer list is stored inside the uv_udp_send_t structure, not allocated on
the heap.
uv_update_time does not overwrite the high 32 bits of uv_loop_t.time.
It merely increments it by one when the low 32 bits have wrapped. That
means that `time` needs to be initialized to zero before
uv_update_time() is called for the first time.
uv_fs_poll_t has an embedded uv_timer_t handle that got closed at a time when
the memory of the encapsulating handle might already have been deallocated.
Solve that by moving the poller's state into a structure that is allocated on
the heap and can be freed independently.
Problem: registering two uv_fs_event_t watchers for the same path, then closing
them, caused a segmentation fault. While active, the watchers didn't work right
either, only one would receive events.
Cause: each watcher has a wd (watch descriptor) that's used as its key in a
binary tree. When you call inotify_watch_add() twice with the same path, the
second call doesn't return a new wd - it returns the existing one. That in turn
resulted in the first handle getting ousted from the binary tree, leaving
dangling pointers.
This commit addresses that by storing the watchers in a queue and storing the
queue in the binary tree instead of storing the watchers directly in the tree.
Fixesjoyent/node#3789.
