[discussion] Context behind watchdog process

[nwalters512]

👋 I'm currently working on introducing foreground-child v3 into nyc to fix issues like #57 and istanbuljs/nyc#1535. That PR is here: istanbuljs/nyc#1546

Unfortunately, the watchdog process introduced in v3 is causing some problems. I'm a little fuzzy on the precise details, but nyc does some stuff to make test coverage work even across subprocesses, and the fact that this package now creates an extra process is causing some trouble with the automated tests that assert things about nyc's process tree behavior.

I reviewed the PR that introduced the watchdog process (#52), but I didn't see any discussion of why it was actually introduced or what problem it was trying to solve. Would you be able to provide that context?

Without knowing any of the context: would you be open to a flag to disable the watchdog?

[nwalters512]

Ah, I just found this in the readme:

Note that a SIGKILL will always kill the parent process, but will not proxy the signal to the child process, because SIGKILL cannot be caught. In order to address this, a special "watchdog" child process is spawned which will send a SIGKILL to the child process if it does not terminate within half a second after the watchdog receives a SIGHUP due to its parent terminating.

[frattaro]

I was just looking through #52 -- could src/index.js's child return value have child.watchdog set as the watchdog process (which would need returned in src/watchdog.js), and then nyc would at least be able to identify the watchdog process and ignore it?

edit: or maybe provide the watchdog process info as an argument to the foreground child callback arg