Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: general improvements to timers.md #6937

Closed
wants to merge 1 commit into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented May 23, 2016

Checklist
  • documentation is changed or added
  • the commit message follows commit guidelines
Affected core subsystem(s)

doc (timers)

Description of change

General improvements to timers.md copy

@nodejs/documentation

@jasnell jasnell added doc Issues and PRs related to the documentations. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. labels May 23, 2016
All of the timer functions are globals. You do not need to `require()`
this module in order to use them.
The `timer` module exposes a global API for scheduling callback functions to
execute at some future period of time. Because the timer functions are globals,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

execute is "one-off", period would rather indicate a sequence of time, no? Anyhow this sounds a little bulky.

@eljefedelrodeodeljefe
Copy link
Contributor

Generally LGTM. Good work.


[the Node.js Event Loop]: ../topics/the-event-loop-timers-and-nexttick.html
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this works?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet. Will be double checking the links before landing.
On May 23, 2016 3:57 PM, "Anna Henningsen" notifications@github.com wrote:

In doc/api/timers.md
#6937 (comment):

+[the Node.js Event Loop]: ../topics/the-event-loop-timers-and-nexttick.html

Are you sure this works?


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/pull/6937/files/a8c72718f4500daa613cfe84416f19e8664f6378#r64303631

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so

@mscdex
Copy link
Contributor

mscdex commented May 24, 2016

/cc @Fishrock123


By default, when a timer is scheduled using either `setTimeout()` or
`setInterval()`, the Node.js event loop will continue running as long as the
timer is active. Each of the opaque timer objects returned by these functions
Copy link
Contributor

@Fishrock123 Fishrock123 May 24, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"opaque" should be something along the lines of "internally tracked" or something

i.e. no access to a _handle

@Fishrock123
Copy link
Contributor

Should be blocked by #6206 or that should be incorporated, but I'd like to preserve @bengl's contribution if possible.

It should have already landed I think but I haven't gotten around to it.

@jasnell
Copy link
Member Author

jasnell commented May 24, 2016

@bengl ... looking at #6206, how about we combine efforts into a single PR? I can port your edits on top of mine (keeping it as a separate commit with your name attached).

@bengl
Copy link
Member

bengl commented May 27, 2016

@jasnell Yeah sure. You want me to PR against your branch or you got it?

@jasnell
Copy link
Member Author

jasnell commented May 27, 2016

Either way works!
On May 27, 2016 2:40 PM, "Bryan English" notifications@github.com wrote:

@jasnell https://github.com/jasnell Yeah sure. You want me to PR
against your branch or you got it?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6937 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAa2eZi4KT-7AqEqhXPOQwPXviks2z5Jks5qF2S6gaJpZM4Ik4sD
.

@bengl
Copy link
Member

bengl commented May 27, 2016

@jasnell alright I made a PR against your branch with roughly the same changes (it was easier to do a completely commit than to rebase).

@jasnell
Copy link
Member Author

jasnell commented May 28, 2016

Awesome, thank you. Squashed my commits and pulled yours in.
@Fishrock123 ... LGTY?

@jasnell
Copy link
Member Author

jasnell commented May 28, 2016

@bengl ... made a few additional edits on top .. PTAL

@bengl
Copy link
Member

bengl commented May 28, 2016

LGTM

@benjamingr
Copy link
Member

LGTM

request the timer hold the program open. If the timer is already `ref`d calling
`ref` again will have no effect.
When called, requests that the Node.js event loop *not* exit so long as the
timer is active. Calling `timer.ref()` multiple times will have no effect.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has no effect unless the Timeout was previously unrefed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this does not restore overhead lost by calling unref() -- once you unref it, we'd have to do a linear walk to re-insert it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neither of these comments seem to be necessary to add to the user documentation in this PR.

@jasnell
Copy link
Member Author

jasnell commented Jun 2, 2016

Updated. PTAL

@jasnell
Copy link
Member Author

jasnell commented Jun 3, 2016

If there are no further comments, I will land on Monday

[`clearImmediate`][]. Additional optional arguments may be passed to the
callback.
When called, the `Timeout` object (while active) will not require the Node.js
event loop to remain active. Calling `timout.unref()` multiple times will have
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not incorrect, but I think this is still poorly worded.

When called, the Timeout will not keep the event loop open. When Node.js would exit due to inactivity, this timer will longer be considered as activity, and the program may stop before it calls it's callback.

Maybe that would be better? I agree the wording is hard without having a strong idea of the event loop and handle refedness.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that's any better. Rather than hold this up while we get the wording perfect on this, I'd recommend landing and iterating on it separately in subsequent PRs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, perhaps, but it should probably at least indicate it has an effect on when the process exits. Perhaps the original wording is the best compromise for now then?

@Fishrock123
Copy link
Contributor

LGTM minus nits (particularly the last one)

@bengl bengl mentioned this pull request Jun 6, 2016
2 tasks
@Fishrock123 Fishrock123 removed their assignment Jun 15, 2016
@Fishrock123
Copy link
Contributor

ping @jasnell

@jasnell
Copy link
Member Author

jasnell commented Jun 15, 2016

Will be back on this after I'm back from vacation
On Jun 15, 2016 1:06 PM, "Jeremiah Senkpiel" notifications@github.com
wrote:

ping @jasnell https://github.com/jasnell


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6937 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAa2eaKRtSzCcz4qv6BkCJ3KMN9bk3oUks5qMFtCgaJpZM4Ik4sD
.

@jasnell
Copy link
Member Author

jasnell commented Jun 21, 2016

Updated one final time to address nit

@@ -208,7 +208,7 @@ but rather than loading the module, just return the resolved filename.
[native addons]: addons.html
[timers]: timers.html
[`clearImmediate`]: timers.html#timers_clearimmediate_immediateobject
[`clearInterval`]: timers.html#timers_clearinterval_intervalobject
[`clearInterval`]: timers.html#timers_clearinterval_immediateobject
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this link is incorrect?

@Fishrock123
Copy link
Contributor

LGTM, might want to make sure the link is right though. The other bits can always be addressed in a new PR

@jasnell
Copy link
Member Author

jasnell commented Jun 27, 2016

Updated to address the final round of nits

@Fishrock123
Copy link
Contributor

Seems good, let's land and unblock #6956

Overall improvements to timers.md documentation,

Includes squashed commit from @bengl:

  doc: add timer classes

  The timers returned by `setTimeout` and friends are
  actually instances of `Timeout` and `Immediate`.
  Documenting them as such, so that the `ref` and
  `unref` methods can be identified as methods on
  `Timeout` objects.

  Sparked by discussion in nodejs#5792
jasnell added a commit that referenced this pull request Jun 28, 2016
Overall improvements to timers.md documentation,

Includes squashed commit from @bengl:

  doc: add timer classes

  The timers returned by `setTimeout` and friends are
  actually instances of `Timeout` and `Immediate`.
  Documenting them as such, so that the `ref` and
  `unref` methods can be identified as methods on
  `Timeout` objects.

  Sparked by discussion in #5792

PR-URL: #6937
Reviewed-By: Robert Jefe Lindstaedt <robert.lindstaedt@gmail.com>
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
@jasnell
Copy link
Member Author

jasnell commented Jun 28, 2016

Landed in 86e07b7

@jasnell jasnell closed this Jun 28, 2016
Fishrock123 pushed a commit that referenced this pull request Jul 5, 2016
Overall improvements to timers.md documentation,

Includes squashed commit from @bengl:

  doc: add timer classes

  The timers returned by `setTimeout` and friends are
  actually instances of `Timeout` and `Immediate`.
  Documenting them as such, so that the `ref` and
  `unref` methods can be identified as methods on
  `Timeout` objects.

  Sparked by discussion in #5792

PR-URL: #6937
Reviewed-By: Robert Jefe Lindstaedt <robert.lindstaedt@gmail.com>
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
@Fishrock123 Fishrock123 mentioned this pull request Jul 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants