Before this change, _unrefActive would keep the unrefList sorted when
adding a new timer.
Because _unrefActive is called extremely frequently, this linear scan
(O(n) at worse) would make _unrefActive show high in the list of
contributors when profiling CPU usage.
This commit changes _unrefActive so that it doesn't try to keep the
unrefList sorted. The insertion thus happens in constant time.
However, when a timer expires, unrefTimeout has to go through the whole
unrefList because it's not ordered anymore.
It is usually not large enough to have a significant impact on
performance because:
- Most of the time, the timers will be removed before unrefTimeout is
called because their users (sockets mainly) cancel them when an I/O
operation takes place.
- If they're not, it means that some I/O took a long time to happen, and
the initiator of subsequents I/O operations that would add more timers
has to wait for them to complete.
With this change, _unrefActive does not show as a significant
contributor in CPU profiling reports anymore.
Fixes: https://github.com/joyent/node/issues/8160
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Conflicts:
lib/timers.js
Fixes: https://github.com/nodejs/node-convergence-archive/issues/23
Ref: https://github.com/nodejs/node/issues/268
PR-URL: https://github.com/nodejs/node/pull/2540
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Partially revert 776b73b243.
Following code crashes after backported timer leak fixes:
```javascript
var timer = setInterval(function() {
clearInterval(timer);
}, 10);
timer.unref();
```
Note that this is actually tested in a `test-timers-unref.js`, and is
crashing only with 776b73b243.
Calling `clearInterval` leads to the crashes in case of `.unref()`ed
timers, and might lead to a extra timer spin in case of regular
intervals that was closed during the interval callback. All of these
happens because `.unref()`ed timer has it's own `_handle` and was used
after the `.close()`.
PR-URL: https://github.com/iojs/io.js/pull/1330
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
This change fixes a regression introduced by commit
0d051238be, which contained a typo that
would cause every unrefd interval to fire only once.
Fixes: https://github.com/joyent/node/issues/8900
Reviewed-By: Timothy J Fontaine <tjfontaine@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Uses `null` as the false-y value for `_repeat` as like other properties.
Removes un-reachable statement in setInterval’s `wrapper()`.
PR-URL: https://github.com/iojs/io.js/pull/1272
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Calling this.unref() during the callback of SetTimeout caused the
callback to get executed twice because unref() didn't expect to be
called during that time and did not stop the ref()ed Timeout but
did start a new timer. This commit prevents the new timer creation
when the callback was already called.
Fixes: https://github.com/iojs/io.js/issues/1191
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
PR-URL: https://github.com/iojs/io.js/pull/1231
The common case is where setInterval() is called with two arguments,
the callback and the timeout. Specifying optional arguments in
the parameter list forces common case calls to go through an arguments
adaptor stack frame.
PR-URL: https://github.com/iojs/io.js/pull/1221
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
The common case is where setTimeout() is called with two arguments,
the callback and the timeout. Specifying optional arguments in the
parameter list forces common case calls to go through an arguments
adaptor stack frame.
PR-URL: https://github.com/iojs/io.js/pull/1221
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
setImmediate, setTimeout, and setInterval were called in an inefficient
way, especially in the presence of arguments. This optimization
improves their performance, with special cases for up to 4 arguments.
Performance of setImmediate increases with 35%, setInterval with 60%,
setTimeout with 70%.
PR-URL: https://github.com/iojs/io.js/pull/406
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Christian Tellnes <christian@tellnes.com>
This commit restricts socket timeouts non-negative, finite
numbers. Any other value throws a TypeError or RangeError.
This prevents subtle bugs that can happen due to type
coercion.
Fixes: https://github.com/joyent/node/issues/8618
PR-URL: https://github.com/joyent/node/pull/8884
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Timothy J Fontaine <tjfontaine@gmail.com>
Conflicts:
lib/timers.js
test/simple/test-net-settimeout.js
test/simple/test-net-socket-timeout.js
This commit replaces a number of var statements throughout
the lib code with const statements.
PR-URL: https://github.com/iojs/io.js/pull/541
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The copyright and license notice is already in the LICENSE file. There
is no justifiable reason to also require that it be included in every
file, since the individual files are not individually distributed except
as part of the entire package.
Fixes the following assertion on slow systems, like our ARM buildbot:
$ out/Debug/node test/simple/test-timers-unref.js
node: ../src/async-wrap-inl.h:101: v8::Handle<v8::Value>
node::AsyncWrap::MakeCallback(uint32_t, int,
v8::Handle<v8::Value>*): Assertion `cb_v->IsFunction()' failed.
Aborted
The reason it only manifests on slow systems is that the test starts
a 1 ms interval timer, then defers timer.unref.bind({}) to the next
tick. On fast systems, the test completes in under a millisecond,
before the callback is called.
This commit makes timer.unref() check that the receiver actually has
a timeout callback property.
Fixes#13.
PR-URL: https://github.com/iojs/io.js/pull/165
Reviewed-By: Rod Vagg <rod@vagg.org>
Async Listener was the name of the user-facing JS API, and is being
completely removed. Instead low level hooks directly into the mechanism
that AL used will be introduced in a future commit.
PR-URL: https://github.com/joyent/node/pull/8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>
Turn on strict mode for the files in the lib/ directory. It helps
catch bugs and can have a positive effect on performance.
PR-URL: https://github.com/node-forward/node/pull/64
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
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.
The AsyncListener API has been moved into the "tracing" module in order
to keep the process object free from unnecessary clutter.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
The ability to add/remove an AsyncListener to an object after its
creation was an artifact of trying to get AL working with the domain
module. Now that is no longer necessary and other features are going to
be implemented that would be affected by this functionality. So the code
will be removed for now to simplify the implementation process.
In the future this code will likely be reintroduced, but after some
other more important matters have been addressed.
None of this functionality was documented, as is was meant specifically
for domain specific implementation work arounds.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Before when an AsyncListener object was created and the "create"
callback returned a value, it was necessary to construct a new Object
with the same callbacks but add a place for the new storage value.
Now, instead, a separate storage array is kept on the context which is
used for any return value of the "create" callback. This significantly
reduces the number of Objects that need to be created.
Also added a flags property to the context to quickly check if a
specific callback was available either on the context or on the
AsyncListener instance itself.
Few other minor changes for readability that were difficult to separate
into their own commit.
This has not been optimized yet.
This is a slightly modified revert of bc39bdd.
Getting domains to use AsyncListeners became too much of a challenge
with many edge cases. While this is still a goal, it will have to be
deferred for now until more test coverage can be provided.
The domain module has been switched over to use the domain module API as
much as currently possible. There are still some hooks in the
EventEmitter, but hopefully we can remove those in the future.
AsyncListener is a JS API that works in tandem with the AsyncWrap class
to allow the user to be alerted to key events in the life cycle of an
asynchronous event. The AsyncWrap class has its own MakeCallback
implementation that core will be migrated to use, and uses state sharing
techniques to allow quicker communication between JS and C++ whether the
async event callbacks need to be called.
Achieve a minor speed-up by looking up the timeout callback on the timer
object by using an array index rather than a named property.
Gives a performance boost of about 1% on the misc/timers benchmarks.
This saves a few calls to gettimeofday which can be expensive, and
potentially subject to clock drift. Instead use the loop time which
uses hrtime internally.
fixes#5497
When an internal api needs a timeout, they should use
timers._unrefActive since that won't hold the loop open. This solves
the problem where you might have unref'd the socket handle but the
timeout for the socket was still active.
Test case:
var t = setInterval(function() {}, 1);
process.nextTick(t.unref);
Output:
Assertion failed: (args.Holder()->InternalFieldCount() > 0),
function Unref, file ../src/handle_wrap.cc, line 78.
setInterval() returns a binding layer object. Make it stop doing that,
wrap the raw process.binding('timer_wrap').Timer object in a Timeout
object.
Fixes#4261.
Before this patch calling `socket.setTimeout(0xffffffff)` will result in
signed int32 overflow in C++ which resulted in assertion error:
Assertion failed: (timeout >= -1), function uv__io_poll, file
../deps/uv/src/unix/kqueue.c, line 121.
see #5101
When calling setImmediate with extra arguments the this keyword in the
callback would refer to the global object, but when not calling
setImmediate with extra arguments this would refer to the returned
handle object.
This commit fixes that inconsistency so its always set handle object.
The handle object was chosen for performance reasons.
This adds a process._fatalException method which is called into from
C++ in order to either emit the 'uncaughtException' method, or emit
'error' on the active domain.
The 'uncaughtException' event is an implementation detail that it would
be nice to deprecate one day, so exposing it as part of the domain
machinery is not ideal.
Fix#4375
Ensure that the delay >= 0 when detaching the timer from the queue. Fixes the
following assertion:
uv_timer_start: Assertion `timeout >= 0' failed.
No test included, it's timing sensitive.
