[issue20934] test_multiprocessing is broken by design

STINNER Victor added the comment: I made different attempts, but at the end, we kept the status quo: some tests use an hardcoded timeout. When a test fails, I increase the timeout. That's not perfect, but nobody came up with a better approach, and it's not a deal. -- resolution: ->

[issue20934] test_multiprocessing is broken by design

Changes by ddve...@ucar.edu : -- nosy: +ddve...@ucar.edu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue20934] test_multiprocessing is broken by design

Antoine Pitrou added the comment: When relying on the timeout feature of various system APIs (e.g. waiting on a semaphore), there isn't much of an alternative to actually waiting a certain amount of time, and measuring the resulting delay. Other tests in the stdlib do this, which is indeed fra

[issue20934] test_multiprocessing is broken by design

Changes by Ned Deily : -- nosy: +sbt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/ma

[issue20934] test_multiprocessing is broken by design

New submission from Andreas Schwab: This comment say it all: CHECK_TIMINGS = False # making true makes tests take a lot longer # and can sometimes cause some non-serious # failures because some calls block a bit #