base::Timer should actually cancel the delayed tasks that it posts |
|||
Issue descriptionInternally the base::Timer variants post a delayed task to fire the timer. If the Timer is deleted or stopped before that task executes then some internal state is cleared, to cause the task to be a no-op when it runs. Instead of running no-op tasks, we should use e.g. CancelableClosure in the Timer implementation, to have internal Timer tasks properly cancelled as soon as they are no longer needed, and enable TaskScheduler/SequenceManager cancelled-task optimizations to be applied consistently.
,
Jan 4
,
Jan 4
,
Jan 7
Re #1: base::Timer isn't a multi-threaded API, as such; it is sequence-affine while the timer is running, and must be stopped on that same sequence before it can be deleted, etc, on a new sequence. That matches the Invalidate/dereference requirements of WeakPtr, so there shouldn't be a problem using WeakPtr-based cancellation.
,
Jan 7
It isn't **meant to be** multi-threaded but I've been on a multi year effort to make the sequence-checks happy (almost there!) |
|||
►
Sign in to add a comment |
|||
Comment 1 by gab@chromium.org
, Jan 4