-
Notifications
You must be signed in to change notification settings - Fork 30k
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
net: inline and simplify onSocketEnd #18607
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.
SGTM
lib/net.js
Outdated
@@ -667,6 +640,16 @@ function onread(nread, buffer) { | |||
maybeDestroy(self); |
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 wonder if this if
statement can be removed. readable
is automatically set to false
when 'end'
is emitted and maybeDestroy()
is called by the handler below.
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.
Yeah, but end
hasn’t necessarily been emitted here. But you’re right, the handler below was supposed to be in the else
block for this.
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.
Yes but if I'm not wrong 'end'
will not be emitted on the same tick, so why aren't we only relying on the 'end'
event? Is it to avoid attaching a listener?
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.
Is it to avoid attaching a listener?
Yes, I assume that’s it. Maybe it isn’t that important?
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 don't know, I don't think it will make a big difference but there is also no real advantage in removing the "fast case" so let's keep it as is :)
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.
FWIW we are now emitting '_socketEnd'
and attaching the listener all the time as 'end'
is not emitted on the same tick.
I also think this branch can create a race where 'close'
can be emitted before 'end'
as _handle.close()
is called before the 'end'
event is emitted if maybeDestroy()
succeeds.
TL;DR I think it's better to always rely on the 'end'
event.
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.
TL;DR I think it's better to always rely on the
'end'
event.
I am cool with that if we can agree that the fast-pathing is not worth it … I like the simplicity :)
Updated!
lib/net.js
Outdated
self.write = writeAfterFIN; | ||
self.destroySoon(); | ||
} | ||
|
||
// internal end event so that we know that the actual socket | ||
// is no longer readable, and we can start the shutdown | ||
// procedure. No need to wait for all the data to be consumed. |
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 we remove this event ('_socketEnd'
) or is it kept to avoid possible breakage?
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.
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.
Gotcha.
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.
LGTM with CI and CITGM green
lib/net.js
Outdated
@@ -664,7 +644,13 @@ function onread(nread, buffer) { | |||
|
|||
if (self.readableLength === 0) { | |||
self.readable = false; |
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.
Sorry to pester but this should be no longer needed now. readableLength
is 0
so 'end'
will be emitted on the next tick and it will already set readable
to false
.
It's also possible that the 'end'
event will never be emitted, for example if onread()
returns an error before reaching this point, so I wonder if it's better to only add the 'end'
listener here instead of the constructor.
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.
this should be no longer needed now
Hm, I could have sworn there were test failures when I tired that… anyway, it seems to pass now, so: Done!
It's also possible that the
'end'
event will never be emitted, for example ifonread()
returns an error before reaching this point, so I wonder if it's better to only add the'end'
listener here instead of the constructor.
That’s not really the common case, is it? I don’t think I have a strong preference.
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.
Indeed it isn't, I'm perfectly fine with this as is. Thanks for bearing with me.
e2319db
to
d689778
Compare
lib/net.js
Outdated
self.readable = false; | ||
maybeDestroy(self); | ||
}*/ |
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 please remove the commented code?
283eb9d
to
ea9254e
Compare
ad319df
to
ddefbbc
Compare
ddefbbc
to
ec1a014
Compare
Rebased with a minor conflict |
Landed in 281d00e 🎉 |
PR-URL: nodejs#18607 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs#18607 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Should this be backported to |
PR-URL: nodejs#18607 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Backport-PR-URL: #19194 PR-URL: #18607 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs#18607 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
net