Comment 4 for bug 1506021

Reviewed: https://review.openstack.org/234770
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ddaee9f060c8fd1585d3e06e04eb301518ff90e0
Submitter: Jenkins
Branch: master

commit ddaee9f060c8fd1585d3e06e04eb301518ff90e0
Author: John Schwarz <email address hidden>
Date: Wed Oct 14 15:39:33 2015 +0300

    Keep reading stdout/stderr until after kill

    Currently, when calling AsyncProcess.stop(), the code stops the stdout
    and stderr readers and kills the process. There exists an end case (as
    described in the bug report) in which after the readers have been
    stopped the sub-process will generate a substantial amount of outputs to
    either fd. Since the 'subprocess' module is launched with
    subprocess.PIPE as stdout/stderr, and since Linux's pipes can be filled
    to the point where writing new data to them will block, this may cause a
    deadlock if the sub-process has a signal handler for the signal (for
    example, the process is handling SIGTERM to produce a graceful exit of
    the program).

    Therefore, this patch proposes to only kill the readers until AFTER
    wait() returned and the process truly died. Also, relying on _kill_event
    had to cease since invoking its send() method caused a logical loop back
    to _kill, causing eventlet errors.

    A different possible solution is closing the stdout/stderr pipes. Alas,
    this may raise an exception in the sub-process ("what? No stdout?!
    Crash!") and defeats the 'graceful' part of the process.

    Closes-Bug: #1506021
    Change-Id: I506c41c634a8d656d81a8ad7963412b834bdfa5b