x86 Windows7 3.7:
http://buildbot.python.org/all/#/builders/111/builds/299

test_crash (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ... 26.57s ok
...
test_crash (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ... 90.96s FAIL
...

======================================================================
FAIL: test_crash (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\test_concurrent_futures.py", line 131, in tearDown
    self.assertLess(dt, 60, "synchronization issue: test lasted too long")
AssertionError: 90.95560574531555 not less than 60 : synchronization issue: test lasted too long


This buildbot is known to be slow.

See also bpo-33715.

Hum, I guess that the fix is to use a timeout of 5 minutes instead of 1 minute. It's ok if the buildbot is slow.

Moreover, it would be interesting to replace time.time() with time.monotonic().

Recent failure (fail then pass):
http://buildbot.python.org/all/#/builders/58/builds/1031

======================================================================
FAIL: test_crash (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_concurrent_futures.py", line 131, in tearDown
    self.assertLess(dt, 60, "synchronization issue: test lasted too long")
AssertionError: 62.650086402893066 not less than 60 : synchronization issue: test lasted too long

+    def tearDown(self):
+        self.executor.shutdown(wait=True)
+        dt = time.time() - self.t1
+        if test.support.verbose:
+            print("%.2fs" % dt, end=' ')
+        self.assertLess(dt, 60, "synchronization issue: test lasted too long")

This code has been added by:

commit aebac0b55a1e3addb93ec7992046a4f9561b4175
Author: Antoine Pitrou <solipsis@pitrou.net>
Date:   Thu Mar 24 15:47:39 2011 +0100

    Add tests for the atexit hook in concurrent.futures (part of #11635)


What is the purpose of having an hardcoded maximum test execution duration? If a test takes 2 seconds instead of 1, it means that the test found a design issue in concurrent.futures? Or it would mean that the test has a bug?

We have many buildbots which are super slow, so I proposed to increase the maximum duration to 5 minutes instead of 1 minute to quickly repair buildbots.

But with 5 minutes, I'm not sure that the check is still useful. 

@Antoine: do you recall the rationale for this check?

I don't remember :-/  It's probably ok to increase the timeout, though.

New changeset 3ad8decd76c736f393755537aeb19b5612c21761 by Pablo Galindo in branch 'master':
bpo-33716, test_concurrent_futures: increase timeout (GH-7828)
https://github.com/python/cpython/commit/3ad8decd76c736f393755537aeb19b5612c21761

New changeset b89776fb1b000f73a62850bea78e5b3434bd7e9a by Miss Islington (bot) in branch '3.7':
bpo-33716, test_concurrent_futures: increase timeout (GH-7828)
https://github.com/python/cpython/commit/b89776fb1b000f73a62850bea78e5b3434bd7e9a

New changeset 8df4770e8d2c9ebd49c5e4d073eef3a5bc805cfc by Victor Stinner in branch '3.6':
bpo-33716, test_concurrent_futures: increase timeout (GH-7828) (GH-8264)
https://github.com/python/cpython/commit/8df4770e8d2c9ebd49c5e4d073eef3a5bc805cfc

The issue has been working around by increasing the timeout from 1 minute to 5 minutes.

resolution: fixed
stage: patch review -> resolved