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

net: inline and simplify onSocketEnd #18607

Closed
wants to merge 1 commit into from

Conversation

addaleax
Copy link
Member

@addaleax addaleax commented Feb 6, 2018

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

net

@nodejs-github-bot nodejs-github-bot added the net Issues and PRs related to the net subsystem. label Feb 6, 2018
@addaleax
Copy link
Member Author

addaleax commented Feb 6, 2018

Copy link
Member

@lpinca lpinca left a 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);
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@lpinca lpinca Feb 7, 2018

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?

Copy link
Member Author

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?

Copy link
Member

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 :)

Copy link
Member

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.

Copy link
Member Author

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.
Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

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

@lpinca It’s still used in another location … I think after #18608 things could be refactored that way, yes

Copy link
Member

Choose a reason for hiding this comment

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

Gotcha.

Copy link
Member

@mcollina mcollina left a 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;
Copy link
Member

@lpinca lpinca Feb 8, 2018

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.

Copy link
Member Author

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 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.

That’s not really the common case, is it? I don’t think I have a strong preference.

Copy link
Member

@lpinca lpinca Feb 9, 2018

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.

@addaleax addaleax force-pushed the net-simplify-onsocketend branch from e2319db to d689778 Compare February 9, 2018 15:34
@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 10, 2018
@addaleax
Copy link
Member Author

@BridgeAR
Copy link
Member

lib/net.js Outdated
self.readable = false;
maybeDestroy(self);
}*/
Copy link
Member

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?

@BridgeAR BridgeAR removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 16, 2018
@addaleax addaleax force-pushed the net-simplify-onsocketend branch from 283eb9d to ea9254e Compare February 20, 2018 23:07
@addaleax
Copy link
Member Author

@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 20, 2018
@addaleax addaleax force-pushed the net-simplify-onsocketend branch 3 times, most recently from ad319df to ddefbbc Compare February 21, 2018 19:36
@addaleax addaleax force-pushed the net-simplify-onsocketend branch from ddefbbc to ec1a014 Compare February 21, 2018 19:44
@addaleax
Copy link
Member Author

Rebased with a minor conflict

New CI: https://ci.nodejs.org/job/node-test-commit/16422/

@BridgeAR
Copy link
Member

Landed in 281d00e 🎉

@BridgeAR BridgeAR closed this Feb 22, 2018
BridgeAR pushed a commit to BridgeAR/node that referenced this pull request Feb 22, 2018
PR-URL: nodejs#18607
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@addaleax addaleax deleted the net-simplify-onsocketend branch February 22, 2018 17:12
addaleax added a commit to addaleax/node that referenced this pull request Feb 26, 2018
PR-URL: nodejs#18607
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins
Copy link
Contributor

Should this be backported to v9.x-staging? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on label.

lpinca pushed a commit to lpinca/node that referenced this pull request Mar 7, 2018
PR-URL: nodejs#18607
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
MylesBorins pushed a commit that referenced this pull request Mar 7, 2018
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]>
@MylesBorins MylesBorins mentioned this pull request Mar 7, 2018
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
PR-URL: nodejs#18607
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. net Issues and PRs related to the net subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants