* Don't set referer if already set
* fetch: Send referer and npm-session headers
* run-script: Support --parseable and --json
* list runnable scripts (Evan Lucas)
* Use marked instead of ronn for html docs
* Check SHA before using files from cache
* adduser: allow change of the saved password
* Make `npm install` respect `config.unicode`
* Fix lifecycle to pass `Infinity` for config env value
* Don't return 0 exit code on invalid command
* cache: Handle 404s and other HTTP errors as errors
* bump tap dep, make tests stderr a bit quieter
* Resolve ~ in path configs to env.HOME
* Include npm version in default user-agent conf
* npm init: Use ISC as default license, use save-prefix for deps
* Many test and doc fixes
Commit f9ced08 switches V8 on Linux over from gettimeofday() to
clock_getres() and clock_gettime(). As of glibc 2.17, those functions
live in libc. For older versions, we need to pull them in from librt.
Fixes the following link-time error;
Release/obj.target/deps/v8/tools/gyp/libv8_base.a(platform-posix.o):
In function `v8::internal::OS::Ticks()':
platform-posix.cc:(.text+0x93c):
undefined reference to `clock_gettime'
platform-posix.cc:(.text+0x989):
undefined reference to `clock_getres'
Fixes #7514.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Date.now() indirectly calls gettimeofday() on Linux and that's a system
call that is extremely expensive on virtualized systems when the host
operating system has to emulate access to the hardware clock.
Case in point: output from `perf record -c 10000 -e cycles:u -g -i`
for a benchmark/http_simple bytes/8 benchmark with a light load of
50 concurrent clients:
53.69% node node [.] v8::internal::OS::TimeCurrentMillis()
|
--- v8::internal::OS::TimeCurrentMillis()
|
|--99.77%-- v8::internal::Runtime_DateCurrentTime(v8::internal::Arguments, v8::internal::Isolate*)
| 0x23587880618e
That's right - over half of user time spent inside the V8 function that
calls gettimeofday().
Notably, nearly all system time gets attributed to acpi_pm_read(), the
kernel function that reads the ACPI power management timer:
32.49% node [kernel.kallsyms] [k] acpi_pm_read
|
--- acpi_pm_read
|
|--98.40%-- __getnstimeofday
| getnstimeofday
| |
| |--71.61%-- do_gettimeofday
| | sys_gettimeofday
| | system_call_fastpath
| | 0x7fffbbaf6dbc
| | |
| | |--98.72%-- v8::internal::OS::TimeCurrentMillis()
The cost of the gettimeofday() system call is normally measured in
nanoseconds but we were seeing 100 us averages and spikes >= 1000 us.
The numbers were so bad, my initial hunch was that the node process was
continuously getting rescheduled inside the system call...
v8::internal::OS::TimeCurrentMillis()'s most frequent caller is
v8::internal::Runtime_DateCurrentTime(), the V8 run-time function
that's behind Date.now(). The timeout handling logic in lib/http.js
and lib/net.js calls into lib/timers.js and that module will happily
call Date.now() hundreds or even thousands of times per second.
If you saw exports._unrefActive() show up in --prof output a lot,
now you know why.
That's why this commit makes V8 switch over to clock_gettime() on Linux.
In particular, it checks if CLOCK_REALTIME_COARSE is available and has
a resolution <= 1 ms because in that case the clock_gettime() call can
be fully serviced from the vDSO.
It speeds up the aforementioned benchmark by about 100% on the affected
systems and should go a long way toward addressing the latency issues
that StrongLoop customers have been reporting.
This patch will be upstreamed as a CR against V8 3.26. I'm sending it
as a pull request for v0.10 first because that's what our users are
running and because the delta between 3.26 and 3.14 is too big to
reasonably back-port the patch. I'll open a pull request for the
master branch once the CR lands upstream.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Signed-off-by: Fedor Indutny <fedor@indutny.com>
* isaacs, Robert Kowalski, Benjamin Coe: Test Improvements
* isaacs doc: Add canonical url
* isaacs view: handle unpublished packages properly
* Raynos (Jake Verbaten) do not log if silent
* Julian Gruber fix no such property error
* isaacs npmconf@0.1.14
* Thorsten Lorenz adding save-prefix configuration option
* isaacs npm-registry-client@0.4.7
* isaacs cache: treat missing versions as a 404
* isaacs cache: Save shasum, write resolved/etc data to cache
* isaacs cache: Always fetch root doc
* isaacs cache: don't repack unnecessarily from tmp
* Andrey Kislyuk Don't crash if shrinkwrap-dependencies were not passed in pkginfo
* Robert Kowalski fix link in faq
* Jean Lauliac Add a peerDependencies section in package.json doc
* isaacs read-installed@2.0.2
Fix possible deadlock, when handles are sent in both direction
simultaneously. In such rare cases, both sides may queue their
`NODE_HANDLE_ACK` replies and wait for them.
fix #7465
`process.uptime()` interface will return the amount of time the
current process has been running. To achieve this it was caching the
`uv_uptime` value at program start, and then on the call to
`process.uptime()` returning the delta between the two values.
`uv_uptime` is defined as the number of seconds the operating system
has been up since last boot. On sunos this interface uses `kstat`s
which can be a significantly expensive operation as it requires
exclusive access, but because of the design of `process.uptime()` node
*had* to always call this on start. As a result if you had many node
processes all starting at the same time you would suffer lock
contention as they all tried to read kstats.
Instead of using `uv_uptime` to achieve this, the libuv loop already
has a concept of current loop time in the form of `uv_now()` which is
in fact monotonically increasing, and already stored directly on the
loop. By using this value at start every platform performs at least
one fewer syscall during initialization.
Since the interface to `uv_uptime` is defined as seconds, in the call
to `process.uptime()` we now `uv_update_time` get our delta, divide by
1000 to get seconds, and then convert to an `Integer`. In 0.12 we can
move back to `Number::New` instead and not lose precision.
Caveat: For some platforms `uv_uptime` reports time monotonically
increasing regardless of system hibernation, `uv_now` interface is
also monotonically increasing but may not reflect time spent in
hibernation.
Socket may become not `readable`, but http should not rely on this
property and should not think that it means that no data will ever
arrive from it. In fact, it may arrive in a next tick and, since
`this.push(null)` was already called, it will result in a error like
this:
Error: stream.push() after EOF
at readableAddChunk (_stream_readable.js:143:15)
at IncomingMessage.Readable.push (_stream_readable.js:123:10)
at HTTPParser.parserOnBody (_http_common.js:132:22)
at Socket.socketOnData (_http_client.js:277:20)
at Socket.EventEmitter.emit (events.js:101:17)
at Socket.Readable.read (_stream_readable.js:367:10)
at Socket.socketCloseListener (_http_client.js:196:10)
at Socket.EventEmitter.emit (events.js:123:20)
at TCP.close (net.js:479:12)
fix #6784
Previously the build artifacts did not include a signed timestamp, so
when the certificate expired the validation of the artifact would fail.
Now we sign against a timestamp server such that the artifact will
always be valid regardless of the disposition of the certificate.
Closes #7360 and #7059.
Ensure that OpenSSL has enough entropy (at least 256 bits) for its PRNG.
The entropy pool starts out empty and needs to fill up before the PRNG
can be used securely.
OpenSSL normally fills the pool automatically but not when someone
starts generating random numbers before the pool is full: in that case
OpenSSL keeps lowering the entropy estimate to thwart attackers trying
to guess the initial state of the PRNG.
When that happens, we wait until enough entropy is available, something
that normally should never take longer than a few milliseconds.
Fixes #7338.
The default entropy source is /dev/urandom on UNIX platforms, which is
okay but we can do better by seeding it from OpenSSL's entropy pool.
On Windows we can certainly do better; on that platform, V8 seeds the
random number generator using only the current system time.
Fixes #6250.
NB: This is a back-port of commit 7ac2391 from the master branch that
for some reason never got back-ported to the v0.10 branch.
The default on UNIX platforms in v0.10 is different and arguably worse
than it is with master: if no entropy source is provided, V8 3.14 calls
srandom() with a xor of the PID and the current time in microseconds.
That means that on systems with a coarse system clock, the initial
state of the PRNG may be easily guessable.
The situation on Windows is even more dire because there the PRNG is
seeded with only the current time... in milliseconds.
* Documentation upgrades
* Fix glob bug which prevents proper README publishing
* node-gyp upgrade to 0.13
* Documentation updates
* Add --save-exact to save an exact dep (instead of a range)
* alias 't' to 'test'
Turn off -Werror when building V8, it hits -Werror=unused-local-typedefs
with g++ 4.8. The warning itself is harmless so don't abort the build.
This was originally implemented in commit d2ab314e back in 2011 but the
build process has gone through a few iterations since then, that change
no longer works.
Fix the following valgrind warning:
Conditional jump or move depends on uninitialised value(s)
at 0x7D64E7: v8::internal::GlobalHandles::IterateAllRootsWithClassIds(v8::internal::ObjectVisitor*) (global-handles.cc:613)
by 0x94DCDC: v8::internal::NativeObjectsExplorer::FillRetainedObjects() (profile-generator.cc:2849)
# etc.
This was fixed upstream in r12903 and released in 3.15.2 but that commit
was never back-ported to the 3.14 branch that node.js v0.10 uses.
The code itself works okay; this commit simply shuffles the clauses in
an `if` statement to check that the node is in use before checking its
class id (which is uninitialized if the node is not in use.)
When sending a socket to a child process via IPC pipe,
`child_process.js` picks a raw UV handle from `_handle` property, sends
it, and assigns `null` to the property. Sending the same socket twice
was resulting in a runtime error, since we weren't handling the empty
`_handle` case.
In case of `null` `_handle` we should send just a plain text message
as passed it was passed to `.send()` and ignore the handle, letting
users handle such cases themselves instead of throwing the error at
runtime.
fix #5469
It's currently not really possible to compile native add-ons with
-fvisibility=hidden because that also hides the struct containing
the module definition.
The NODE_MODULE() and NODE_MODULE_DECL() macros are structured in
a way that makes it impossible to add a visibility attribute manually
so there is no escape hatch there.
That's why this commit adds an explicit visibility attribute to
the module definition. It doesn't help with node.js releases that
are already out there but at least it improves the situation going
forward.
If two timers run on the same tick, and the first timer uses a domain,
and then catches an exception and disposes of the domain, then the
second timer never runs. (And even if the first timer does not dispose
of the domain, the second timer could run under the wrong domain.)
This happens because timer.js uses "process.nextTick()" to schedule
continued processing of the timers for that tick. However, there was
an exception inside a domain, then "process.nextTick()" runs under
the domain of the first timer function, and will do nothing if
the domain has been disposed.
To avoid this, we temporarily save the value of "process.domain"
before calling nextTick so that it does not run inside any domain.
Previously if you cached process.nextTick and then require('domain')
subsequent nextTick() calls would not be caught because enqueued
functions were taking the wrong path. This keeps nextTick to a single
function reference and changes the implementation details after domain
has been required.
This makes it so that the user may pass in a
`createConnection()` option, and they don't have
to pass `agent: false` at the same time.
Also adding a test for the `createConnection` option,
since none was in place before.
See #7014.
Ensure that the behavior of `assert.deepEqual` does not depend on
argument ordering when comparing an `arguments` object with a
non-`arguments` object.
