Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upFeature request: ChildProcess 'spawn' event #35288
Comments
|
It's not hard to implement, see diff. Feel free to steal for a PR, no attribution needed. Needs docs and tests, however. diff --git a/lib/internal/child_process.js b/lib/internal/child_process.js
index 31d9f02df3..5672f3429f 100644
--- a/lib/internal/child_process.js
+++ b/lib/internal/child_process.js
@@ -400,6 +400,8 @@ ChildProcess.prototype.spawn = function(options) {
this._handle.close();
this._handle = null;
throw errnoException(err, 'spawn');
+ } else {
+ process.nextTick(onSpawnNT, this);
}
this.pid = this._handle.pid;
@@ -465,6 +467,11 @@ function onErrorNT(self, err) {
}
+function onSpawnNT(self) {
+ self.emit('spawn');
+}
+
+
ChildProcess.prototype.kill = function(sig) {
const signal = sig === 0 ? sig :Apropos this:
Yes, but there's a subtlety that is likely to trip up some people (mostly the magical thinker kind): while That caveat also applies to |
|
@bnoordhuis can I take this up? |
|
I'd also like to claim this issue |
|
@zenflow I'm sorry, I thought you were a maintainer. Sure you claim the issue as you raised the issue. Thanks, looking forward! |
|
Thanks @kaushik94 |
The new event signals that the subprocess has spawned successfully and no 'error' event will be emitted from failing to spawn. This change is accompanied by a new test for the logical ordering of events emitted by a typical ChildProcess object. Fixes: nodejs#35288
The new event signals that the subprocess has spawned successfully and no 'error' event will be emitted from failing to spawn. Fixes: nodejs#35288
Is your feature request related to a problem? Please describe.
After calling
child_process.spawn, I'd like to know when the child process has successfully spawned and there's no longer the possibility of an 'error' event from failing to spawn (i.e. error type # 1 in the docs for that 'error' event, e.g.EPERM,ENOENT).Currently I just wait 100 milliseconds (after calling
child_process.spawn), and if the child process hasn't emitted an 'error' event by that time, I assume it spawned successfully. My code looks something like this:This seems to work, but I'm not sure how reliable it is, and anyways, it is certainly a hack.
I'm wondering if there could be a better (more correct) way..
Describe the solution you'd like
Is there some point of execution in Node where we know there was no error spawning the child process?
If so, we could introduce a new 'spawn' event for the ChildProcess class, to be emitted at that point in execution?
That would remove the need for the unreliable hack I described above.
It would also work nicely with Node.js's
events.oncefunction. For example, the code from above could be updated like this:const { spawn } = require('child_process'); -const { promisify } = require('util'); const { once } = require('events'); -const timeout = promisify(setTimeout); async function doSomethingWithChildProcess(){ const subprocess = spawn(...spawnArgs); try { - await Promise.race([ - timeout(100), - once(subprocess, 'error').then(([error]) => Promise.reject(error)) - ]); + await once(subprocess, 'spawn'); } catch (error) { // handle error spawning child process return; } // do something with the running child process... }Describe alternatives you've considered
Just the hack I described above (of expecting any error spawning to happen within 100 milliseconds of calling
child_process.spawn).I can't think of any other possible solutions at this time.