Does release of task runner block on currently running tasks?

14 views
Skip to first unread message

Christian Fremerey

unread,
Jan 31, 2019, 12:31:16 PM1/31/19
to scheduler-dev, Wei Lee
Dear List Members,

I ran into a question in a code review [1] where I couldn't find a definitive answer from the documentation at [2]. The question is essentially whether or not the following is safe:

class A {
 public:
  A()
      : task_runner_(base::CreateSequencedTaskRunnerWithTraits(
            {base::TaskPriority::USER_VISIBLE})) {}
  ~A() = default;

  void SomeMethod() {
    task_runner_->PostTask(FROM_HERE,
                           base::BindOnce(&A::SomeMethodToBeRunOnTaskRunner,
                                          base::Unretained(this)));
  }

  void SomeMethodToBeRunOnTaskRunner() {
    // ...
  }

 private:
  scoped_refptr<base::SequencedTaskRunner> task_runner_;
};

This basically comes down to whether or not releasing |task_runner_| created via 
CreateSequencedTaskRunnerWithTraits would guarantee to block while the posted 
task is executing and guarantee to discard the task if it had not yet started 
executing. My assumption is that it does not give any such guarantee, but I 
realize that it could be implemented this way.

François Doray

unread,
Jan 31, 2019, 12:52:49 PM1/31/19
to Christian Fremerey, scheduler-dev, Wei Lee
We *never* wait for tasks to complete when a reference to a TaskRunner obtained from CreateSequencedTaskRunnerWithTraits() is released. Tasks already posted to a TaskRunner can run normally after references to the TaskRunner have been released. It is useful to keep all the state accessed from a SequencedTaskRunner in a "helper" class whose deletion is scheduled on that SequencedTaskRunner using OnTaskRunnerDeleter. See example in this CL: http://crrev.com/c/1416271/15/chrome/browser/performance_monitor/system_monitor.h.  Let us know if you need more help.



--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CADVxpgrHfrGGOh4p8zE2%2Bq5LNx5mtSUZFFSikfe8FmMY-MSMSQ%40mail.gmail.com.

Gabriel Charette

unread,
Feb 1, 2019, 5:16:02 PM2/1/19
to Christian Fremerey, scheduler-dev, Wei Lee
On Thu, Jan 31, 2019 at 12:31 PM Christian Fremerey <chfr...@chromium.org> wrote:
Dear List Members,

I ran into a question in a code review [1] where I couldn't find a definitive answer from the documentation at [2]. The question is essentially whether or not the following is safe:

class A {
 public:
  A()
      : task_runner_(base::CreateSequencedTaskRunnerWithTraits(
            {base::TaskPriority::USER_VISIBLE})) {}
  ~A() = default;

  void SomeMethod() {
    task_runner_->PostTask(FROM_HERE,
                           base::BindOnce(&A::SomeMethodToBeRunOnTaskRunner,
                                          base::Unretained(this)));
  }

  void SomeMethodToBeRunOnTaskRunner() {
    // ...
  }

 private:
  scoped_refptr<base::SequencedTaskRunner> task_runner_;
};

This basically comes down to whether or not releasing |task_runner_| created via 
CreateSequencedTaskRunnerWithTraits would guarantee to block while the posted 
task is executing and guarantee to discard the task if it had not yet started 
executing. My assumption is that it does not give any such guarantee, but I 
realize that it could be implemented this way.

Actually, since it's ref-counted, I don't think it could even be implemented this way if we wanted to. Other refs could have been handed out and/or refs could have been obtained from the tasks themselves through SequencedTaskRunnerHandle::Get() (and that even after |task_runner_| is released). There really is no way to guarantee a sequence is dead (short of creating your own and controlling a very small set of tasks that run on it; but even then, that's hard to make future-proof).

Thanks Francois for the new docs :)
 
--

Christian Fremerey

unread,
Feb 1, 2019, 5:26:43 PM2/1/19
to Gabriel Charette, scheduler-dev, Wei Lee
Thanks, Francois and Garbiel for your answers and insights.
Also thank for updating the docs!
Reply all
Reply to author
Forward
0 new messages