* fix gyp build
* don't require libexecinfo, it's not there
* libpthread doesn't implement sem_timedwait(), fall back to sem_wait()
Upstreamed in https://codereview.chromium.org/11421013/
The purpose of this file was to remap the old libeio API to the new one.
We dropped libeio in ee77a6a and this file has been broken ever since.
Ergo, remove it.
While updating the readline test cases to test both "terimal: false" and
"terminal: true" mode, it turned out that the test case testing utf8 chars
being sent over multiple write() calls was failing. The solution is to use
a string_decoder instance when parsing the "keypress" events.
Before this commit, readline was inconsistent in whether or not it would emit
"line" events with or without the trailing "\n" included. When "terminal"
mode was true, then there would be no "\n", when it was false, then the "\n"
would be present. However, the trailing "\n" doesn't add much, and most of the
time people just end up stripping it manually.
Part of #4243.
* Added isIP method to make use of inet_pton to cares_wrap.cc
* Modified net.isIP() to make use of new C++ isIP method.
* Added new tests to test-net-isip.js.
DTrace on Linux should not be enabled by default because not all systems will
have the proper headers installed. Only enable when --with-dtrace is passed to
the configure script.
`url.format` should escape ? and # chars in pathname, and # chars in
search, because they change the semantics of the operation otherwise.
Don't escape % chars, or anything else. (see: #4082)
Inform V8 that the zlib context object is tied to a large off-heap buffer.
This makes the GC run more often (in theory) and improves the accuracy of
--trace_external_memory.
In zlibBuffer(), don't wait for the garbage collector to reclaim the zlib memory
but release it manually. Reduces memory consumption by a factor of 10 or more
with some workloads.
Test case:
function f() {
require('zlib').deflate('xxx', g);
}
function g() {
setTimeout(f, 5);
}
f();
Observe RSS memory usage with and without this commit. After 10,000 iterations,
RSS stabilizes at ~35 MB with this commit. Without, RSS is over 300 MB and keeps
growing.
Cause: whenever the JS object heap hits the high-water mark, the V8 GC sweeps
it clean, then tries to grow it in order to avoid more sweeps in the near
future. Rule of thumb: the bigger the JS heap, the lazier the GC can be.
A side effect of a bigger heap is that objects now live longer. This is harmless
in general but it affects zlib context objects because those are tied to large
buffers that live outside the JS heap, on the order of 16K per context object.
Ergo, don't wait for the GC to reclaim the memory - it may take a long time.
Fixes#4172.