[issue19399] sporadic test_subprocess failure

2013-10-25 Thread Roundup Robot
Roundup Robot added the comment: New changeset af67cfcd4089 by Tim Peters in branch 'default': Issue #19399: fix sporadic test_subprocess failure. http://hg.python.org/cpython/rev/af67cfcd4089 -- nosy: +python-dev ___ Python tracker

[issue19399] sporadic test_subprocess failure

2013-10-25 Thread Tim Peters
Changes by Tim Peters : -- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior ___ Python tracker ___ __

[issue19399] sporadic test_subprocess failure

2013-10-25 Thread Tim Peters
Changes by Tim Peters : -- assignee: -> tim.peters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue19399] sporadic test_subprocess failure

2013-10-25 Thread Tim Peters
Tim Peters added the comment: I think I'll change Thread.join() to just return if a timeout <= 0 is passed. The docs don't say anything about what Thread.join() does with a negative timeout, but at least in 2.7.5 it happened to just return. No point being gratuitously more demanding ;-) ---

[issue19399] sporadic test_subprocess failure

2013-10-25 Thread Tim Peters
Tim Peters added the comment: BTW, if subprocess did check the return value, it would see that the timeout already expired, and the test would pass. -- ___ Python tracker ___ __

[issue19399] sporadic test_subprocess failure

2013-10-25 Thread Tim Peters
Tim Peters added the comment: Well, when a timeout is specified, .join() passes exactly the timeout passed to _it_ to ._wait_for_tstate_lock(), which in turn passes exactly the same timeout to .acquire(). So the negative value must be coming from _communicate() (the self.stdout_thread.joi

[issue19399] sporadic test_subprocess failure

2013-10-25 Thread Antoine Pitrou
New submission from Antoine Pitrou: It looks like this may be the symptom of a buglet in Thread.join: == ERROR: test_communicate_timeout (test.test_subprocess.ProcessTestCase)