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.

Sign up for GitHub

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

timers: do not expose .unref()._handle._list #8422

Closed
wants to merge 3 commits into from
Closed

timers: do not expose .unref()._handle._list #8422

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
29bd0ce
timers: do not expose .unref()._handle._list
Fishrock123 Sep 6, 2016
33b213c
[Squash] set _list to undefined
Fishrock123 Apr 10, 2017
dc49d91
[Squash] remove comment
Fishrock123 Apr 20, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions lib/timers.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -538,6 +538,9 @@ Timeout.prototype.unref = function() {
}

var handle = reuse(this);
if (handle) {
handle._list = undefined;
}

this._handle = handle || new TimerWrap();
this._handle.owner = this;
Expand Down
16 changes: 16 additions & 0 deletions test/parallel/test-timers-unref-reuse-no-exposed-list.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
'use strict';
Copy link

Choose a reason for hiding this comment

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

Does this need a license block now that #10155 landed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

... No? It did not have previous attribution? (It's new?)

Copy link

Choose a reason for hiding this comment

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

OK, it's been a while I haven't added a file to the repository, and it seems files added in the recent past did not include a license block, so it sounds good to me!


require('../common');
const assert = require('assert');

const timer1 = setTimeout(() => {}, 1).unref();
assert.strictEqual(timer1._handle._list, undefined,
'timer1._handle._list should be undefined');

// Check that everything works even if the handle was not re-used.
setTimeout(() => {}, 1);
const timer2 = setTimeout(() => {}, 1).unref();
// Note: It is unlikely that this assertion will be hit in a failure.
Copy link

Choose a reason for hiding this comment

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

That comment seems to be specific to a previous version of this PR where it would throw in that case. I don't think it's relevant in the final version.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not really, the comment states if that were to fail, i.e. the conditional was removed, node will explode internally rather than triggering this assertion.

Copy link

Choose a reason for hiding this comment

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

Why would "a failure" be specifically that "the conditional was removed"? This is anticipating the future, and not reflecting the current state of the code base. Without the context of what this PR looked like in an intermediate version, this comment doesn't make any sense.

I still think it's not relevant.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can't think of how this will change without removing handle re-use... Are you saying that a comment that either: might be useful or not matter at all would be better off not being there at all? Isn't that every comment ever?

That bit of code does primarily test that conditional though, that isn't a problem IMO. We have added plenty of test code for code coverage that would be similar.

Copy link

@misterdjules misterdjules Apr 13, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

The test code itself is great, and the comment above:

// Check that everything works even if the handle was not re-used.

is both necessary and sufficient to explain why this test code is present.

On the other hand, I find the comment:

// Note: It is unlikely that this assertion will be hit in a failure.
// Instead, timers.js will likely throw a TypeError internally.

confusing and detrimental to the understanding of that test because it does not reflect the current state of the implementation. Instead it describes what could happen if the code was changed in a specific way, that is if a conditional was removed.

I don't think we want to start documenting every possible way this test could fail depending on an infinite list of possible changes, or by definition we will end up with an infinite list of comments.

// Instead, timers.js will likely throw a TypeError internally.
assert.strictEqual(timer2._handle._list, undefined,
'timer2._handle._list should be undefined');