Is there a race condition in child process creation/error listening?

[pushkin-]

• Node.js Version: 7.9.0
• OS: Windows 10
• Scope (install, code, runtime, meta, other?): runtime
• Module (and version) (if relevant): child_process

Is there a race condition here?

const proc = cp.spawn(...);
proc.on("error", (err) => throw err);

What would happen if the process failed to spawn before we added the error handler? Would we never get the error?

I suppose the solution is to ping the process to test that it's alive.

[gireeshpunathil]

@pushkin- nice question!

• there is no race condition, but there is a consideration Node is taking as to what is defined as a condition for which error emission is necessitated.

• for example, while you spawn a process, there are a number of control flow points at which the process can fail: fork, post-fork stream setup, dependent library link failure, load failure, exec file format failure, execute permission failure, resource failure, etc. followed by soft startup failure in the target process itself - input failure, configuration failure, bootup failure etc... There is no generic way of telling at what point in the execution flow we deem the target process has passed the bootup sequence and now all errors are deemed runtime errors.

• the current definition of runtime errors and non-runtime errors are by far the most natural, but are open for debate if there are convincing use cases to support: the logic can be found in this section of the spawn method

Hope this helps.

[pushkin-]

@gireeshpunathil I looked at the source you linked to, and it looks like we're raising the error event on the next tick, so there indeed isn't a race condition.

However, I'm having trouble following what you said in your comment. Are you just saying that certain errors are considered non-runtime errors, and for those Node throws an exception, and other errors are deemed runtime error for which an error event is raised on the next tick?

In that case, should I technically be putting a try/catch around my process creation?

[gireeshpunathil]

@pushkin- yes, you got it absolutely right. errors in the preparatory phase: non-runtime errors, so absorb them in a try-catch block, and anything afterwards - runtime errors, catch them in the error listeners.