-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
http2: implement ref() and unref() on sessions #17620
Conversation
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 saw this comment made by @addaleax about
uv_prepare_t
, but I don't really understand it. To me, this code change seems sufficient, but maybe I'm missing something.
The code has changed since then. :)
Should
ClientHttp2Session
instances beunref
d by default?
I don’t think so; if you have an active network connection, you usually want that to keep the event loop alive.
Should these be available on
ServerHttp2Session
objects as well? (my thought is no)
Why not? :)
Should calling
ref
/unref
be a no-op after the session has been destroyed, or could it return an error?
It seems doing nothing is what net.Socket
does, so I’d go with that? I think that’s what this code already does, right? 👍
doc/api/http2.md
Outdated
|
||
#### clienthttp2session.unref() | ||
<!-- YAML | ||
added: ??? (TODO) |
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.
Can you use added: REPLACEME
here? That way it gets picked up automatically by the release tooling :)
lib/internal/http2/core.js
Outdated
@@ -1086,6 +1086,18 @@ class ClientHttp2Session extends Http2Session { | |||
} | |||
return stream; | |||
} | |||
|
|||
ref() { | |||
if (this[kSocket]) { |
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.
Can you also check whether typeof this[kSocket].ref === 'function'
? HTTP/2 supports any stream as the underlying socket, so .ref
might not be present at that point.
The test file that checks that is test/parallel/test-http2-generic-streams.js
, if you want to extend that – I think calling .ref()
there would crash right now?
I thought Seems like it's worthwhile to ensure |
@kjin I think those are different things – |
Yep, I understand that Currently |
826acba
to
8714f6f
Compare
@addaleax Thanks for the feedback so far, I've updated the PR to make |
This should wait to land until after #17406, as is may need to be updated based on those changes. |
Hmm, but if the session isn't transporting any data (just kept open because of HTTP/2 semantics) I don't see a good reason why it should keep the event loop alive. |
lib/internal/http2/core.js
Outdated
ref() { | ||
if (this[kSocket]) { | ||
assert(this[kSocket]._handle); | ||
if (typeof this[kSocket]._handle.ref === 'function') { |
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.
Why not just this[kSocket].ref
? That’s what’s being called anyway, right?
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.
For generic duplex streams this[kSocket]
is a JSStreamWrap
object, which doesn't have a handle.ref
field.
Actually, this makes me think that net.Socket
itself should be checking that _handle.ref
is a function, rather than here. I'll add a trailing commit that does so, we can drop it if there is already a good rationale for not checking in net
.
@TimothyGu This is just calling through to the underlying socket, the HTTP2 session itself won’t keep anything open |
f601654
to
0346126
Compare
0346126
to
c64f6b1
Compare
@jasnell @addaleax I've rebased the PR on master. The only conflict was in the docs, since I moved I can understand if it's not in the scope of this PR to move the |
79739eb
to
f29e6a7
Compare
f29e6a7
to
b3d2513
Compare
PR-URL: #17620 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
landed in 120ea9b |
PR-URL: nodejs#17620 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Backport-PR-URL: #18050 PR-URL: #17620 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Backport-PR-URL: #18050 PR-URL: #17620 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Thanks for the ping, not sure why this hasn't been backported yet. |
Backport-PR-URL: nodejs#18050 PR-URL: nodejs#17620 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Backport-PR-URL: #18050 Backport-PR-URL: #20456 PR-URL: #17620 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Fixes #16617
This is my stab at adding
ref
andunref
onClientHttp2Session
instances. It seems mostly straightforward, but there were a few questions I had in mind about this code change:ClientHttp2Session
instances beunref
d by default?ServerHttp2Session
objects as well? (my thought is no)ref
/unref
be a no-op after the session has been destroyed, or could it return an error?I saw this comment made by @addaleax about
uv_prepare_t
, but I don't really understand it. To me, this code change seems sufficient, but maybe I'm missing something.Also, I updated the docs to separate
ClientHttp2Session
fromHttp2Session
... which seemed to make sense considering that this distinction is present even in the codebase.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
http2