Sorry for not getting to this as fast as I'd like. The original problem [an aborted task reaching task_finished()] is hard to reproduce and might be some sort of race. I currently protect against it with this in the queue, just for safety reasons:
- self.running_tasks.remove(task)
- self.finished_tasks += 1
- self.start_next_task()
+ # only remove known tasks and then start the next one,
+ # this shall avoid issues with an aborted task reaching finished()
+ # via done()
+ if task in self.running_tasks:
+ self.running_tasks.remove(task)
+ self.finished_tasks += 1
+ self.start_next_task()
And yeah, the commit clears up some of the confusion. Anything that makes the derivation (with overloading) less ambiguous will be an improvement, so e.g. task state would be reflected by the task objects properly, and the task queue could handle (= recognize) aborted and paused tasks without relying on only its own arrays, such as running_tasks, waiting_tasks and the finished_tasks count.
Sorry for not getting to this as fast as I'd like. The original problem [an aborted task reaching task_finished()] is hard to reproduce and might be some sort of race. I currently protect against it with this in the queue, just for safety reasons:
- self.running_ tasks.remove( task) next_task( ) tasks.remove( task) next_task( )
- self.finished_tasks += 1
- self.start_
+ # only remove known tasks and then start the next one,
+ # this shall avoid issues with an aborted task reaching finished()
+ # via done()
+ if task in self.running_tasks:
+ self.running_
+ self.finished_tasks += 1
+ self.start_
And yeah, the commit clears up some of the confusion. Anything that makes the derivation (with overloading) less ambiguous will be an improvement, so e.g. task state would be reflected by the task objects properly, and the task queue could handle (= recognize) aborted and paused tasks without relying on only its own arrays, such as running_tasks, waiting_tasks and the finished_tasks count.