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

handle_wrap: IsRefed -> Unrefed, no isAlive check #6204

Merged
merged 1 commit into from
Apr 25, 2016

Conversation

Fishrock123
Copy link
Contributor

Checklist
  • tests and code linting passes
  • a test and/or benchmark is included
  • the commit message follows commit guidelines
Affected core subsystem(s)

handle_wrap

Description of change

This fixes my perceived usability issues with #5834, which has not landed in any release except v6 RCs. This should not be considered a breaking change due to that.

It is useful if you have a handle, even if it has been closed, to be able to inspect whether that handle was unrefed or not. As such, I have renamed the method accordingly. If people need to check a handle's aliveness, that is a separate API we should consider exposing.

cc @trevnorris, @jasnell, @cjihrig

@Fishrock123 Fishrock123 added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels Apr 14, 2016
@Fishrock123 Fishrock123 added this to the 6.0.0 milestone Apr 14, 2016
@jasnell
Copy link
Member

jasnell commented Apr 15, 2016

LGTM if @trevnorris and CI are happy

@bnoordhuis
Copy link
Member

bnoordhuis commented Apr 15, 2016

Awkward names, both the old and the new one. What about hasRef?

@Fishrock123
Copy link
Contributor Author

Fishrock123 commented Apr 15, 2016

@bnoordhuis Yeah, but hasRef (& isRefed) implies that it should return false if it is no longer alive.

Maybe UnrefBit, or something?

HandleWrap* wrap = Unwrap<HandleWrap>(args.Holder());

bool refed = IsAlive(wrap) && (wrap->flags_ & kUnref) == 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

There's no message body explaining why you removed the IsAlive() check, so i'm not sure of your rational. Seeing checks removed without explanation make me quiver.

@Fishrock123
Copy link
Contributor Author

Fishrock123 commented Apr 15, 2016

@trevnorris I put it into the post comment:

It is useful if you have a handle, even if it has been closed, to be able to inspect whether that handle was unrefed or not. As such, I have renamed the method accordingly. If people need to check a handle's aliveness, that is a separate API we should consider exposing.

@trevnorris
Copy link
Contributor

@Fishrock123 would you mind putting that into the commit message body? i'm lazy and don't want to have to go look at the PR to find out why a change was made.

@Fishrock123
Copy link
Contributor Author

Will do.

diversario pushed a commit to diversario/node that referenced this pull request Apr 15, 2016
Helps in implementation of nodejs#6204, where some options passed to
`createSecurePair()` are ignored before this patch.

These options are very helpful if someone wants to pass
`options.servername` or `options.SNICallback` to securepair.

PR-URL: nodejs#2441
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Trott pushed a commit to Trott/io.js that referenced this pull request Apr 20, 2016
Helps in implementation of nodejs#6204, where some options passed to
`createSecurePair()` are ignored before this patch.

These options are very helpful if someone wants to pass
`options.servername` or `options.SNICallback` to securepair.

PR-URL: nodejs#2441
Reviewed-By: Fedor Indutny <fedor@indutny.com>
@jasnell
Copy link
Member

jasnell commented Apr 25, 2016

ping @Fishrock123 ... if you still want this in v6 it needs to be wrapped up by tomorrow morning.

@trevnorris
Copy link
Contributor

LGTM, IF the additional information requested above is added to the git message body.

This fixes my perceived usability issues with 7d8882b. Which, at the
time of writing, has not landed in any release except v6 RCs. This
should not be considered a breaking change due to that.

It is useful if you have a handle, even if it has been closed, to be
able to inspect whether that handle was unrefed or not. As such, this
renames the method accordingly. If people need to check a handle's
aliveness, that is a separate API we should consider exposing.

Refs: nodejs#5834
PR-URL: nodejs#6204
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
@Fishrock123
Copy link
Contributor Author

Updated with description and metadata. CI before landing: https://ci.nodejs.org/job/node-test-pull-request/2392/

@Fishrock123
Copy link
Contributor Author

plinux failure looks like a flake: test-debug-port-from-cmdline.js timeout.

@Fishrock123 Fishrock123 merged commit 9bb5a5e into nodejs:master Apr 25, 2016
@Fishrock123
Copy link
Contributor Author

Fishrock123 commented Apr 25, 2016

Man I'm just having terrible luck with this one. This patch attempting to use this feature crashes test-handle-wrap-close-abort.js..

'./node test/parallel/test-handl…' terminated by signal SIGSEGV (Address boundary error)

diff --git a/lib/timers.js b/lib/timers.js
index dc2506e..9fb247c 100644
--- a/lib/timers.js
+++ b/lib/timers.js
@@ -133,8 +133,6 @@ function insert(item, unrefed) {
     list = new TimersList(msecs, unrefed);
     L.init(list);
     list._timer._list = list;
-
-    if (unrefed === true) list._timer.unref();
     list._timer.start(msecs, 0);

     lists[msecs] = list;
@@ -149,7 +147,7 @@ function TimersList(msecs, unrefed) {
   this._idleNext = null; // Create the list with the linkedlist properties to
   this._idlePrev = null; // prevent any unnecessary hidden class changes.
   this._timer = new TimerWrap();
-  this._unrefed = unrefed;
+  if (unrefed === true) this._timer.unref();
   this.msecs = msecs;
 }

@@ -207,7 +205,7 @@ function listOnTimeout() {
   debug('%d list empty', msecs);
   assert(L.isEmpty(list));
   this.close();
-  if (list._unrefed === true) {
+  if (list._timer.unrefed() === true) {
     delete unrefedLists[msecs];
   } else {
     delete refedLists[msecs];

Fishrock123 added a commit to Fishrock123/node that referenced this pull request May 3, 2016
This reverts commit 9bb5a5e.

Refs: nodejs#6395
Refs: nodejs#6204
Refs: nodejs#6401
Refs: nodejs#6382
Fixes: nodejs#6381

Conflicts:
	src/handle_wrap.cc
	test/parallel/test-handle-wrap-isrefed-tty.js
	test/parallel/test-handle-wrap-isrefed.js
Fishrock123 added a commit to Fishrock123/node that referenced this pull request May 11, 2016
This reverts commit 9bb5a5e.

This API is not suitable because it depended on being able to
potentially access the handle's flag after the handle was already
cleaned up. Since this is not actually possible (obviously, oops)
this newer API no longer makes much sense, and the older API is more
suitable.

API comparison:
IsRefed -> Has a strong reference AND is alive. (Deterministic)
Unrefed -> Has a weak reference OR is dead. (Less deterministic)

Refs: nodejs#6395
Refs: nodejs#6204
Refs: nodejs#6401
Refs: nodejs#6382
Fixes: nodejs#6381

PR-URL: nodejs#6546
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>

Conflicts:
	src/handle_wrap.cc
	test/parallel/test-handle-wrap-isrefed-tty.js
	test/parallel/test-handle-wrap-isrefed.js
Fishrock123 added a commit to Fishrock123/node that referenced this pull request May 11, 2016
Rename slightly to HasRef() at bnoordhuis’ request.
Better reflects what we actually do for this check.

Refs: nodejs#6395
Refs: nodejs#6204
Refs: nodejs#6401
Refs: nodejs#6382
Refs: nodejs#6381

PR-URL: nodejs#6546
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
evanlucas pushed a commit that referenced this pull request May 17, 2016
This fixes my perceived usability issues with 7d8882b. Which, at the
time of writing, has not landed in any release except v6 RCs. This
should not be considered a breaking change due to that.

It is useful if you have a handle, even if it has been closed, to be
able to inspect whether that handle was unrefed or not. As such, this
renames the method accordingly. If people need to check a handle's
aliveness, that is a separate API we should consider exposing.

Refs: #5834
PR-URL: #6204
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
evanlucas pushed a commit that referenced this pull request May 17, 2016
This reverts commit 9bb5a5e.

This API is not suitable because it depended on being able to
potentially access the handle's flag after the handle was already
cleaned up. Since this is not actually possible (obviously, oops)
this newer API no longer makes much sense, and the older API is more
suitable.

API comparison:
IsRefed -> Has a strong reference AND is alive. (Deterministic)
Unrefed -> Has a weak reference OR is dead. (Less deterministic)

Refs: #6395
Refs: #6204
Refs: #6401
Refs: #6382
Fixes: #6381

PR-URL: #6546
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>

Conflicts:
	src/handle_wrap.cc
	test/parallel/test-handle-wrap-isrefed-tty.js
	test/parallel/test-handle-wrap-isrefed.js
evanlucas pushed a commit that referenced this pull request May 17, 2016
Rename slightly to HasRef() at bnoordhuis’ request.
Better reflects what we actually do for this check.

Refs: #6395
Refs: #6204
Refs: #6401
Refs: #6382
Refs: #6381

PR-URL: #6546
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
@MylesBorins
Copy link
Contributor

@Fishrock123 is there a reason you removed the dont land label for v4.x? This is causing false positives when auditing missing commits from lts

@Fishrock123
Copy link
Contributor Author

probably because of nodejs/Release#108

@MylesBorins
Copy link
Contributor

ahhh my mistake... I got mixed up between this and the revert issues. Moving to lts-watch. Please feel free to do with the tags what you think is most appropriate

@MylesBorins
Copy link
Contributor

@Fishrock123 this can be moved to don't land correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants