Uh oh!
There was an error while loading. Please reload this page.
net: inline and simplify onSocketEnd - #18607
Conversation
addaleax
commented
Feb 6, 2018
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
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!
There was a problem hiding this comment.
Can we remove this event ('_socketEnd') or is it kept to avoid possible breakage?
There was a problem hiding this comment.
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.
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.
Indeed it isn't, I'm perfectly fine with this as is. Thanks for bearing with me.
e2319db to
d689778Compareaddaleax
commented
Feb 10, 2018
BridgeAR
commented
Feb 10, 2018
There was a problem hiding this comment.
Can you please remove the commented code?
283eb9d to
ea9254eCompareaddaleax
commented
Feb 20, 2018
ad319df to
ddefbbcCompareddefbbc to
ec1a014Compareaddaleax
commented
Feb 21, 2018
Rebased with a minor conflict |
BridgeAR
commented
Feb 22, 2018
Landed in 281d00e 🎉 |
PR-URL: nodejs#18607 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: nodejs#18607 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
commented
Mar 6, 2018
Should this be backported to |
PR-URL: nodejs#18607 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: nodejs#18607 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
net