{{ message }}
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it still work if
this.close()was placed into both of theseifcases? I think that may be a better and more robust patch.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would work as far as I checked. I also made an additional test that has
require('timers')._unrefActive(timer1)and found that the timer handle is not reused in that case. So it is okay.Honestly, I'm not sure whether the following two conditions are equivalent or not. I think the latter is clearly understandable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking is that you only actually want to close the handle if the list was in a pool.
There are more obscure parts of the timers code imo so I don't think it is an issue.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fishrock123
Do you mean that we want to close the TimerWrap handle only if the list is still in a pool?
Does that diff reflects the change you had in mind:
?
I would think that the
ownerproperty represents ownership for a specific timer handle better than the belonging of its timer list to a given timer lists pool, so I have a preference for:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that if we check the closing condition weather the list was in a pool or not.
is better.
Otherwise, I prefer to check owner property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very confused as to why what I originally suggested doesn't do the job just fine?
Keep in mind that
reuse()is called before this if unrefing is actually re-using the handle and it already removed the list from the pool:node/lib/timers.js
Lines 274 to 293 in 75cdc89
Essentially I don't see why we'd bother to check
.owner()if doing it in those conditionals is deterministic anyways?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fishrock123
For the reason I mentioned above:
In other words, it seems it would be more robust to check the
ownerproperty than rely on what seems to be an implementation detail.The solution you're suggesting also duplicates code, and doesn't include any documentation about why the underlying TimerWrap handle should be closed in some cases, and not in others.
What you're suggesting would indeed fix the problem, but it seems to me it would lead to a less robust solution that would be more difficult to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this.
And it is the point that we don't have an agreement with @Fishrock123 from his comment of