lost subprocess output during stop

[mcdonc]

Heath Kehoe provides this analysis:

The problem with losing subprocess stdout/stderr when the subprocess is
stopped is caused by the self.drain() call in Subprocess::stop(). If I
remove the drain() call from the stop() method, the problem is fixed.

Here's why: The drain() method ends up calling handle_read_event() for
the POutputDispatcher instances connected to stdout and stderr (because
their readable() methods always return True while the pipe is still
open). So readfd() is called which will return an empty string because
there very likely isn't any data pending; and that causes
handle_read_event() to close the pipe. But the process is still running,
and about receive its stop signal, so any output it wants to generate
between getting the signal and exiting will be lost (and worse, if the
subprocess generates more than a little output, it may receive a
SIGPIPE. If it wasn't written to handle or ignore that signal, it'll
terminate uncleanly).

Since drain() is called again during Subprocess::finish(), which happens
after the process has actually exited, there's no need to call drain()
earlier.

[mcdonc]

• Fix bug where stopping process would cause process output that happened
  after the stop request was issued to be lost. See
  lost subprocess output during stop #11.

Closed by e19cbc1.