Conversation
28a7570 to
30c54f9
Compare
src/env.cc
Outdated
There was a problem hiding this comment.
Can we add the unit of measurement to duration? E.g. duration_ms if it’s milliseconds?
src/env.cc
Outdated
There was a problem hiding this comment.
tiny style nit: arraysize(args)
src/env.cc
Outdated
There was a problem hiding this comment.
ditto re: adding the unit to the name
(Also, why abs? Can you add a comment?)
src/timers.cc
Outdated
There was a problem hiding this comment.
Is there a reason for not providing these directly on the binding?
There was a problem hiding this comment.
I wondered about that. I don't think so?
|
Thanks @addaleax. I've cleaned up and added some detailed comments. Hope this is better :) |
a0b2f82 to
dc80758
Compare
src/timer_wrap.cc
Outdated
There was a problem hiding this comment.
Is there any possibility of userland native modules depending on this? Is it safe to remove without a deprecation cycle?
/cc @bnoordhuis
There was a problem hiding this comment.
I've done an extensive search and there was not a single module I could find using it. I'm not really sure why someone would want to anyway given that Timer.now() is not that different from process.hrtime() but isn't officially supported.
But also process.binding shouldn't be part of our official deprecation cycle, should it? We broke Gulp in 10.0.0 with changes to contextify and that's a huge module.
(And the TimerWrap itself is impossible to use outside of Node.js.)
|
Does this need a proper deprecation cycle? /cc @nodejs/tsc |
|
Here's CitGM now that it's not broken anymore: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1431/ |
dc80758 to
15b2ddd
Compare
There was a problem hiding this comment.
@eugeneo This test fails without this change. I suspect it has to do with the removal of the HandleWrap, right? Or is there something else at play? Would appreciate you having a look as the author of this test and someone with a lot of understanding of all this tracing stuff. Thanks!
There was a problem hiding this comment.
@nodejs/diagnostics Perhaps some of you might have insight too? Thanks!
This test fails without this change. I suspect it has to do with the removal of the HandleWrap, right? Or is there something else at play? Would appreciate you having a look as the author of this test and someone with a lot of understanding of all this tracing stuff. Thanks!
There was a problem hiding this comment.
It's because timer_wrap.cc uses AsyncWrap::MakeCallback(), which calls AsyncWrap::EmitTraceEventAfter(). Since you no longer use that method, it's not traced any more.
I personally don't feel too strongly but I guess it would be nice to keep the current behavior.
There was a problem hiding this comment.
I wonder if we should do something about Immediates too in that case? But I don't know how to best handle it since there's no longer an AsyncWrap (or obviously a matching provider). All of this trace event stuff is pretty outside of my expertise as far as Node goes so I'm all ears...
Since this is semver-major (and won't land in a release for a while), perhaps we could add a TODO: or start an issue so that more qualified people can chime in (including yourself)?
There was a problem hiding this comment.
I'd be okay with that. In my opinion, AsyncWrap currently conflates too much (mushes too much into a single class) and could use some decoupling.
There was a problem hiding this comment.
LGTM on the test change. I haven't reviewed the rest of the PR.
5ab8e99 to
2b7ae97
Compare
lib/timers.js
Outdated
There was a problem hiding this comment.
I suspect you intended to write 'assign.' :-)
lib/timers.js
Outdated
There was a problem hiding this comment.
This is a functionally null change, right?
There was a problem hiding this comment.
Yeah, it's just cleaner this way since we don't assign each time.
src/env.cc
Outdated
There was a problem hiding this comment.
Can you CHECK_EQ(0, uv_timer_init(...));?
(Not that it can actually fail but that's why it should be CHECK'd.)
src/env.cc
Outdated
There was a problem hiding this comment.
If you're just passing a single argument you can do Local<Value> arg = env->GetNow() and then call into JS with cb->Call(..., 1, &arg).
Not that this is wrong but it's a bit more obvious at the call site that you're just passing one arg.
src/env.cc
Outdated
There was a problem hiding this comment.
I realize you brought this over from timer_wrap.cc but is there a reason you can't handle exceptions in JS land?
There was a problem hiding this comment.
We need to let it go to uncaughtException or domain first. I don't think there's a way to do so in JS?
src/env.cc
Outdated
There was a problem hiding this comment.
Either check that expiry_ms fits in an int or use llabs() (or manually turn it positive.)
There was a problem hiding this comment.
Ah, yeah... didn't even realize!
src/env.cc
Outdated
There was a problem hiding this comment.
uv_ref() and uv_unref() are idempotent, you don't need to check if the timer is ref'd or not.
src/timers.cc
Outdated
There was a problem hiding this comment.
You could also use an anonymous namespace here.
There was a problem hiding this comment.
It's because timer_wrap.cc uses AsyncWrap::MakeCallback(), which calls AsyncWrap::EmitTraceEventAfter(). Since you no longer use that method, it's not traced any more.
I personally don't feel too strongly but I guess it would be nice to keep the current behavior.
There was a problem hiding this comment.
Not sound. process.hrtime() returns the number of nanoseconds since an unspecified point in the past. If that point is the UNIX epoch then this stops working sometime next year because seconds * 1e3 >= 2**32.
There was a problem hiding this comment.
Ok, sounds like it's best to expose getLibuvNow() from internal/timers and just use that then.
|
CI after changes: https://ci.nodejs.org/job/node-test-pull-request/15053/ |
jasnell
left a comment
There was a problem hiding this comment.
LGTM! Thank you for the investigation on the semveriness :-)
|
Just an FYI, while this is marked as "author ready" and could land, I'm hoping to have @Fishrock123 review it. Please don't land until they either review or say they won't have time to do so. |
|
I’m on Vacation. It’l have to wait until during or after JSConf.EU. |
The timers directory test, utilizing FakeTime, has not worked in quite a while and is not truly testing Node.js behaviour. If a similar test is necessary it would be better suited to libuv on which Node.js relies for timers functionality. PR-URL: nodejs#20894 Fixes: nodejs#10154 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Gus Caplan <me@gus.host>
The timers directory test, utilizing FakeTime, has not worked in quite a while and is not truly testing Node.js behaviour. If a similar test is necessary it would be better suited to libuv on which Node.js relies for timers functionality. PR-URL: #20894 Fixes: #10154 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Backport-PR-URL: #22039 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
nodejs#20894 / 2930bd1 was introduced on master which removed an offending line in this doc before linting was applied to test/ in nodejs#22221 / 56103ab. Since 20894 is semver-major, the full changes were not backported.
#20894 / 2930bd1 was introduced on master which removed an offending line in this doc before linting was applied to test/ in #22221 / 56103ab. Since 20894 is semver-major, the full changes were not backported. PR-URL: #22296 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: George Adams <george.adams@uk.ibm.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
#20894 / 2930bd1 was introduced on master which removed an offending line in this doc before linting was applied to test/ in #22221 / 56103ab. Since 20894 is semver-major, the full changes were not backported. PR-URL: #22296 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: George Adams <george.adams@uk.ibm.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Correct the output of async_hooks samples * `TIMERWRAP` has been removed in #20894 * `console.log()` doesn't issue `TTYWRAP` nor `SIGNALWRAP` I don't know which PR caused that `console.log()` is no longer using `TTYWRAP` and `SIGNALWRAP`; I think it was between 8.4.0 and 8.5.0. PR-URL: #24050 Refs: #20894 Reviewed-By: James M Snell <jasnell@gmail.com>
Correct the output of async_hooks samples * `TIMERWRAP` has been removed in #20894 * `console.log()` doesn't issue `TTYWRAP` nor `SIGNALWRAP` I don't know which PR caused that `console.log()` is no longer using `TTYWRAP` and `SIGNALWRAP`; I think it was between 8.4.0 and 8.5.0. PR-URL: #24050 Refs: #20894 Reviewed-By: James M Snell <jasnell@gmail.com>
Correct the output of async_hooks samples * `TIMERWRAP` has been removed in nodejs#20894 * `console.log()` doesn't issue `TTYWRAP` nor `SIGNALWRAP` I don't know which PR caused that `console.log()` is no longer using `TTYWRAP` and `SIGNALWRAP`; I think it was between 8.4.0 and 8.5.0. PR-URL: nodejs#24050 Refs: nodejs#20894 Reviewed-By: James M Snell <jasnell@gmail.com>
Correct the output of async_hooks samples * `TIMERWRAP` has been removed in #20894 * `console.log()` doesn't issue `TTYWRAP` nor `SIGNALWRAP` I don't know which PR caused that `console.log()` is no longer using `TTYWRAP` and `SIGNALWRAP`; I think it was between 8.4.0 and 8.5.0. PR-URL: #24050 Refs: #20894 Reviewed-By: James M Snell <jasnell@gmail.com>
Correct the output of async_hooks samples * `TIMERWRAP` has been removed in #20894 * `console.log()` doesn't issue `TTYWRAP` nor `SIGNALWRAP` I don't know which PR caused that `console.log()` is no longer using `TTYWRAP` and `SIGNALWRAP`; I think it was between 8.4.0 and 8.5.0. PR-URL: #24050 Refs: #20894 Reviewed-By: James M Snell <jasnell@gmail.com>
nodejs/node#20894 / 2930bd1 was introduced on master which removed an offending line in this doc before linting was applied to test/ in nodejs/node#22221 / 56103ab. Since 20894 is semver-major, the full changes were not backported. PR-URL: nodejs/node#22296 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: George Adams <george.adams@uk.ibm.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Remove TimerWrap in favour of
uv_timer_thandle stored on the Environment, more similar to howImmediatescurrently function. Since there's now only a single TimerWrap, it doesn't really make much sense for it to exist at all (hence this PR). In addition, the async stack from the TimerWrap is actually not desirable and every single public module that works with async hooks seems to filter it out anyway.I've also done a quick scan of npm modules and I could not find a single use case of
TimerWrap.now(), which would be the only reason to keep it publicly available. It's also currently impossible for user land to use theTimerWrapgiven howOnTimeoutis implemented (it can only process our own internal lists).This will make it possible to continue further improving our Timers architecture and C++ code.
Fixes: #10154
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes