Just got this:

[255/372/1] test_sched
Warning -- threading._dangling was modified by test_sched
test test_sched failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_sched.py", line 83, in test_cancel_concurrent
    scheduler.cancel(event1)
  File "/home/antoine/cpython/default/Lib/sched.py", line 96, in cancel
    self._queue.remove(event)
ValueError: list.remove(x): x not in list

This is a test only issue.

There are two ways to fix this test. On first simple way we can just increase the timing and hope for a luck. On second more complicated way we should use custom deterministic time and sleep functions. Here is a first way patch to shut up the test failing.

Here is a second way patch. It adds a deterministic non-realtime timer.

+1 for the deterministic version.

The previous patch is broken, here is a fixed, more complicated, patch. May be this class would be useful in other tests.

> The previous patch is broken, here is a fixed, more complicated,
> patch. May be this class would be useful in other tests.

I don't understand what you're gaining with this complicated class: your
class guarantees that the sleepers will be woken up, but it doesn't
guarantee that any user code will actually run.

Perhaps the whole thing would be simpler if your tests used a Queue
instead of a list?

> I don't understand what you're gaining with this complicated class: your
> class guarantees that the sleepers will be woken up, but it doesn't
> guarantee that any user code will actually run.

It guarantees that advance() returns only when all sleepers are sleeping or 
died, and all user code before specified time mark have executed. User code 
running does not take time, only sleeps take time. Actually this class is a 
forward-running time-machine with pause. But it looks overkill here.

> Perhaps the whole thing would be simpler if your tests used a Queue
> instead of a list?

Hmm, I had not occurred to this idea. Indeed, the patch is a little 
complicated (honestly speaking, it is a lot complicated). Here is a more 
simplified patch that uses a queue for synchronization in one direction and 
simple custom timer for synchronization in another direction. Thank you for 
suggestion.

> Actually this class is a 
> forward-running time-machine with pause.

Perhaps you should give it to Guido as a present?

> Perhaps you should give it to Guido as a present?

First I have to find some application for it. Wait for me at the 3013 year.

New changeset ab36d3bb5996 by Serhiy Storchaka in branch '3.3':
Issue #16843: Make concurrent tests for sched module deterministic.
http://hg.python.org/cpython/rev/ab36d3bb5996

New changeset f65eae38f71e by Serhiy Storchaka in branch 'default':
Issue #16843: Make concurrent tests for sched module deterministic.
http://hg.python.org/cpython/rev/f65eae38f71e