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

child_process.flushStdio: resume _consuming streams #4071

Closed

Conversation

davidvgalbraith
Copy link

Hey! I'm new here. Tried to follow all the guidelines. Thanks for your attention!

When a client calls read() with a nonzero argument
on a Socket, that Socket sets this._consuming to true.
It never sets this._consuming back to false.
child_process.flushStdio currently doesn't flush
any streams where _consuming is truthy. But that means
that it never flushes any stream that has ever been read from.
This prevents a child process from ever closing if one of
its streams has been read from, causing issue #4049.

child_process.flushStdio should flush streams even if their
_consuming is set to true. Then it will close even after a read.

When a client calls read() with a nonzero argument
on a Socket, that Socket sets this._consuming to true.
It never sets this._consuming back to false.
child_process.flushStdio currently doesn't flush
any streams where _consuming is truthy. But that means
that it never flushes any stream that has ever been read from.
This prevents a child process from ever closing if one of
its streams has been read from, causing issue nodejs#4049.

child_process.flushStdio should flush streams even if their
_consuming is set to true. Then it will close even after a read.
@ChALkeR ChALkeR added the child_process Issues and PRs related to the child_process subsystem. label Nov 30, 2015
@Fishrock123
Copy link
Contributor

cc @nodejs/streams

@Fishrock123
Copy link
Contributor

const cp = require('child_process');
const common = require('../common');

var p = cp.spawn('yes');
Copy link
Contributor

Choose a reason for hiding this comment

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

Is yes a valid Windows command?

Copy link
Contributor

Choose a reason for hiding this comment

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

I had my coworker on windows type yes into the prompt and it is not a command

Copy link
Contributor

Choose a reason for hiding this comment

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

Can also confirm it is not.

@cjihrig
Copy link
Contributor

cjihrig commented Nov 30, 2015

Is there a reason the test needs to be in sequential instead of parallel?

@cjihrig
Copy link
Contributor

cjihrig commented Nov 30, 2015

A couple of questions about the test, but mostly LGTM. I would like sign off from a streams person if possible.

@davidvgalbraith
Copy link
Author

I moved the test into parallel, and I changed its use of yes to the cross-platform echo, double-checking that it still fails on master and passes on this branch.

const cp = require('child_process');
const common = require('../common');

var p = cp.spawn('echo');
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please make this const.

Make the spawned process object a const, and add assertions to the event handler that the arguments are as expected
@davidvgalbraith
Copy link
Author

I made p a const, and I added validating assertions to the close event handler.

@cjihrig
Copy link
Contributor

cjihrig commented Nov 30, 2015

Started a CI run: https://ci.nodejs.org/job/node-test-pull-request/883/

The linter doesn't like your indentation - https://ci.nodejs.org/job/node-test-linter/434/console

@Fishrock123
Copy link
Contributor

@cjihrig note: currently the CI is private. See #4029 (comment)

@davidvgalbraith
Copy link
Author

How embarrassing. I've indented the requisite two spaces. Forsooth I can't see anything at the CI link.

@Fishrock123
Copy link
Contributor

@davidvgalbraith could you run make jslint? That should do the trick. :)

@davidvgalbraith
Copy link
Author

make jshint is looking green as of davidvgalbraith@127a82e.

@cjihrig
Copy link
Contributor

cjihrig commented Nov 30, 2015

@Fishrock123 good catch about the CI being private.

@davidvgalbraith the CI looks fine. There were a couple failures unrelated to this change. LGTM

cjihrig pushed a commit that referenced this pull request Dec 1, 2015
When a client calls read() with a nonzero argument
on a Socket, that Socket sets this._consuming to true.
It never sets this._consuming back to false.
ChildProcess.flushStdio() currently doesn't flush
any streams where _consuming is truthy. But, that means
that it never flushes any stream that has ever been read from.
This prevents a child process from ever closing if one of
its streams has been read from, causing issue #4049. This
commit allows consuming streams to be flushed, and the
child process to emit a close event.

Fixes: #4049
PR-URL: #4071
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@cjihrig
Copy link
Contributor

cjihrig commented Dec 1, 2015

Thanks! Landed in 34b535f

@cjihrig cjihrig closed this Dec 1, 2015
@jasnell
Copy link
Member

jasnell commented Dec 2, 2015

@cjihrig ... would you consider this a bug fix (and thus suitable for LTS) or an add?

@cjihrig
Copy link
Contributor

cjihrig commented Dec 2, 2015

I would consider this a bug fix.

@silverwind
Copy link
Contributor

Looks like this new test here is failing on CentOS:

https://ci.nodejs.org/job/node-test-commit-linux/1387/nodes=centos5-32/tapResults/
https://ci.nodejs.org/job/node-test-commit-linux/1387/nodes=centos5-64/tapResults/

    test-child-process-flush-stdio.js   
    # Mismatched &lt;anonymous&gt; function calls. Expected 1, actual 0.
    # at Object.&lt;anonymous&gt; (/home/iojs/build/workspace/node-test-commit-linux/nodes/centos5-64/test/parallel/test-child-process-flush-stdio.js:8:22)
    # at Module._compile (module.js:399:26)
    # at Object.Module._extensions..js (module.js:406:10)
    # at Module.load (module.js:345:32)
    # at Function.Module._load (module.js:302:12)
    # at Function.Module.runMain (module.js:431:10)
    # at startup (node.js:138:18)
    # at node.js:976:3

@cjihrig
Copy link
Contributor

cjihrig commented Dec 3, 2015

Yes. See #4125

rvagg pushed a commit that referenced this pull request Dec 5, 2015
When a client calls read() with a nonzero argument
on a Socket, that Socket sets this._consuming to true.
It never sets this._consuming back to false.
ChildProcess.flushStdio() currently doesn't flush
any streams where _consuming is truthy. But, that means
that it never flushes any stream that has ever been read from.
This prevents a child process from ever closing if one of
its streams has been read from, causing issue #4049. This
commit allows consuming streams to be flushed, and the
child process to emit a close event.

Fixes: #4049
PR-URL: #4071
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@rvagg rvagg mentioned this pull request Dec 17, 2015
@MylesBorins
Copy link
Contributor

Not going to land this until we are ready to land #4215 into LTS... I think it needs a bit more time

MylesBorins pushed a commit that referenced this pull request Jan 13, 2016
When a client calls read() with a nonzero argument
on a Socket, that Socket sets this._consuming to true.
It never sets this._consuming back to false.
ChildProcess.flushStdio() currently doesn't flush
any streams where _consuming is truthy. But, that means
that it never flushes any stream that has ever been read from.
This prevents a child process from ever closing if one of
its streams has been read from, causing issue #4049. This
commit allows consuming streams to be flushed, and the
child process to emit a close event.

Fixes: #4049
PR-URL: #4071
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this pull request Jan 19, 2016
When a client calls read() with a nonzero argument
on a Socket, that Socket sets this._consuming to true.
It never sets this._consuming back to false.
ChildProcess.flushStdio() currently doesn't flush
any streams where _consuming is truthy. But, that means
that it never flushes any stream that has ever been read from.
This prevents a child process from ever closing if one of
its streams has been read from, causing issue #4049. This
commit allows consuming streams to be flushed, and the
child process to emit a close event.

Fixes: #4049
PR-URL: #4071
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Jan 19, 2016
scovetta pushed a commit to scovetta/node that referenced this pull request Apr 2, 2016
When a client calls read() with a nonzero argument
on a Socket, that Socket sets this._consuming to true.
It never sets this._consuming back to false.
ChildProcess.flushStdio() currently doesn't flush
any streams where _consuming is truthy. But, that means
that it never flushes any stream that has ever been read from.
This prevents a child process from ever closing if one of
its streams has been read from, causing issue nodejs#4049. This
commit allows consuming streams to be flushed, and the
child process to emit a close event.

Fixes: nodejs#4049
PR-URL: nodejs#4071
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
child_process Issues and PRs related to the child_process subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants