src: use libuv's refcounting directly #6395
Merged
Uh oh!
There was an error while loading. Please reload this page.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
bnoordhuis added the c++ 
Member
addaleax commented Apr 26, 2016
Nice, LGTM! |
Contributor
cjihrig commented Apr 26, 2016
LGTM |
Contributor
Fishrock123 commented Apr 26, 2016
This still has the same behavior though? i.e. Should we just track this in JS? NOT lgtm since this will interfere with likely reverts of my commits. |
Member
addaleax commented Apr 26, 2016
@Fishrock123 fwiw, #6381 passes when replayed on top of this |
MemberAuthor
bnoordhuis commented Apr 26, 2016
I'm not sure what 'this' refers to. The reference count, liveliness, or something else? |
Member
jasnell commented Apr 26, 2016
LGTM. Should this go into v6? |
MemberAuthor
bnoordhuis commented Apr 26, 2016
Well... #6401 might block that. |
Don't implement an additional reference counting scheme on top of libuv. Libuv is the canonical source for that information so use it directly. PR-URL: nodejs#6395 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
This also updates the tests to expect that a closed handle has no reference count. PR-URL: nodejs#6395 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Verify that a second call to handle.close() is a no-op. PR-URL: nodejs#6395 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
bnoordhuisforce-pushed the handlewrap-refcounting branch from fd087d5 to 4282405CompareMemberAuthor
bnoordhuis commented Apr 27, 2016
Seeing how the reverts never landed (#6401 (comment)), I went ahead and landed this in 23818c6...4282405. |
Contributor
Fishrock123 commented Apr 27, 2016
That's fine; but this is also a behavior breaker and will make fixing my stupid API problems even more complex. |
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#6382Fixes: nodejs#6381 Conflicts: src/handle_wrap.cc test/parallel/test-handle-wrap-isrefed-tty.js test/parallel/test-handle-wrap-isrefed.js
3 tasks
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#6382Fixes: nodejs#6381 PR-URL: nodejs#6546 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Trevor Norris <[email protected]> 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 <[email protected]> Reviewed-By: Trevor Norris <[email protected]>
2 tasks
evanlucas pushed a commit that referenced this pull request May 17, 2016
Don't implement an additional reference counting scheme on top of libuv. Libuv is the canonical source for that information so use it directly. PR-URL: #6395 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
evanlucas pushed a commit that referenced this pull request May 17, 2016
This also updates the tests to expect that a closed handle has no reference count. PR-URL: #6395 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
evanlucas pushed a commit that referenced this pull request May 17, 2016
Verify that a second call to handle.close() is a no-op. PR-URL: #6395 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
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: #6382Fixes: #6381 PR-URL: #6546 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Trevor Norris <[email protected]> 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 <[email protected]> Reviewed-By: Trevor Norris <[email protected]>
Contributor
MylesBorins commented Jun 1, 2016
I'm setting this as don't land... @Fishrock123 / @bnoordhuis please let me know if that is incorrect |
Contributor
Fishrock123 commented Jun 2, 2016
Hmmmm, seems fine unless @bnoordhuis Thinks it's important to backport. May need to be manual because this depended on my handle wrap additions. |
MemberAuthor
bnoordhuis commented Jun 2, 2016
I'm okay with having it back-ported (as long as I don't have to do the work - hah!) but it's not strictly necessary from a 'bug fixes only' perspective. |
Contributor
MylesBorins commented Jun 2, 2016
I'll put it on watch and see if it lands nicely... if it doesn't we just won't do it 😄 |
Contributor
MylesBorins commented Jun 2, 2016
@bnoordhuis this does not land cleanly and I've added the dont-land label. Please feel free to revisit this if you like |
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
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.
The first commit is cleanup:
The second one is what I think the logic should be:
R=@Fishrock123
CI: https://ci.nodejs.org/job/node-test-pull-request/2398/