Problem
-------
When running a subprocess that writes a lot of data to stdout, then
exits, it is possible to read all data from stdout, then, when calling
waitpid(2), to be told the subprocess has not yet exited.
pexpect would then call read_nonblocking and block for a full 30
seconds, because there remains no more data on stdout.
Solution
--------
Add new parameter, poll_exit to read_nonblocking so that select(2) is
called at shorter intervals than previously done, but still up until
timeout specified, doing a poll for waitpid(2) at regular intervals.
This ensures that no longer than (default, 0.15) seconds elapse, instead
of the default of 30.
Testing
-------
Includes travis changes for python3.4, also disabling use_site_packages
which doesn't appear supported any longer (most builds have been failing
for some time). Additionally, a 'death' flag for checking select(2)
after waitpid(2) was necessary only for python3.4 on travis, i could not
reproduce locally.
All existing unit tests, of course. However, as a race condition, it is
not possible to reliably reproduce, it may require anywhere from 1 to 5
minutes of looping to cause it to reproduce, so it was not put into base
tests.
A simple program was authored::
TIMEOUT=1
def test_2():
while True:
stime = time.time()
child = pexpect.spawn('ls -lR /dev',
timeout=TIMEOUT)
child.expect(pexpect.EOF)
elapsed = time.time() - stime
print('got eof in {0:0.2f} in pid {1}'
.format(elapsed, child.pid))
assert math.floor(elapsed) < TIMEOUT, elapsed
Without this change, this program will raise an exception after several
dozen runs, hitting the race condition.
With this change, I have been executing this program for several thousand
iterations without failed assertion.
PLEASE CONFER
-------------
@takluyver, with this change, I think we may also delete the
self.__irix_hack and its surrounding hack -- and even the first
self.isalive() check just before this change, for "some systems
such as Solaris" without any penalty in performance.
What do you think?