net: fix ambiguity in EOF handling #9066
Conversation
|
Nice one. I imagine there is very little chance to write a unit test for this, right? if not, LGTM. |
|
@mcollina I actually just got an idea on how to do this, but wanted to gather some preliminary feedback first. |
|
Added test. |
|
@indutny Test not showing up here... (Forgot to push maybe? Or need to force-push maybe?) |
`end` MUST always be emitted **before** `close`. However, if a handle will invoke `uv_close_cb` immediately, or in the same JS tick - `close` may be emitted first.
indutny
force-pushed
the
fix/ambiguity-in-net
branch
from
9920f17
to
6e38e76
Compare
|
@Trott sorry, just pushed it! |
|
Stress test to make sure there's no unexpected flakiness hidden in the test somewhere: https://ci.nodejs.org/job/node-stress-single-test/994/ (Failures on the two win2008* jobs can be ignored, I think.) |
|
LGTM if no CI oddities arise. |
|
|
||
| process.on('exit', () => { | ||
| assert.deepStrictEqual(events, [ 'end', 'close' ]); | ||
| }); |
There was a problem hiding this comment.
Would something like this work?
s.on('end', common.mustCall(() => {
s.on('close', common.mustCall(() => {}));
}));... so you can get rid of events and the exit listener.
There was a problem hiding this comment.
On one hand - yes, on the other - if this test will ever error, the error message will be more informative.
|
LGTM |
|
Landed in 31196ea, thank you! |
`end` MUST always be emitted **before** `close`. However, if a handle will invoke `uv_close_cb` immediately, or in the same JS tick - `close` may be emitted first. PR-URL: #9066 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ilkka Myller <[email protected]>
`end` MUST always be emitted **before** `close`. However, if a handle will invoke `uv_close_cb` immediately, or in the same JS tick - `close` may be emitted first. PR-URL: #9066 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ilkka Myller <[email protected]>
|
@indutny this lands cleanly on v4 and v6. Is this something we should consider backporting? |
|
@thealphanerd yep |
`end` MUST always be emitted **before** `close`. However, if a handle will invoke `uv_close_cb` immediately, or in the same JS tick - `close` may be emitted first. PR-URL: #9066 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ilkka Myller <[email protected]>
`end` MUST always be emitted **before** `close`. However, if a handle will invoke `uv_close_cb` immediately, or in the same JS tick - `close` may be emitted first. PR-URL: #9066 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ilkka Myller <[email protected]>
Checklist
make -j8 test(UNIX), orvcbuild test nosign(Windows) passesAffected core subsystem(s)
net
Description of change
endMUST always be emitted beforeclose. However, if a handlewill invoke
uv_close_cbimmediately, or in the same JS tick -closemay be emitted first.
cc @nodejs/collaborators