Why would you not expect this to work in the first place? I'd think a relatively simple use case for schedulers is using a single thread to do the work of a Timer instead of spawning a thread for every Timer. In that sort of use case, the "timer worker" is constantly pulling tasks and other thread(s) are adding them; for an empty event queue, if thread A adds a task 'a' that delays for 10 minutes and thread B adds a task 'b' that delays for 1 minute, the time at which task 'b' executes changes dramatically based on which thread squeaks out a win on the race to insert into the scheduler queue. As long as task 'a' wins the race, a million other tasks could be scheduled to run before it, but all of them will be stuck behind task 'a' no matter their priority or delay.

It should be possible to fix this without too much trouble (and without polling loops), but it would require scheduler to remove the option to customize delayfunc; you'd change the scheduler's RLock to a Condition, have mutations to the event queue notify the Condition, and the run method would replace sleeping outside the locked scope with a wait w/timeout inside it.

The only thing blocking a fix for this is backwards compatibility. If people are okay with breaking that, I'll happily contribute a patch, but I want some indication of whether back compat can be sacrificed to make sched actually useful in threaded contexts.