security/sandbox/chromium/base/task_runner.h

changeset 0
6474c204b198
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/security/sandbox/chromium/base/task_runner.h	Wed Dec 31 06:09:35 2014 +0100
     1.3 @@ -0,0 +1,153 @@
     1.4 +// Copyright (c) 2012 The Chromium Authors. All rights reserved.
     1.5 +// Use of this source code is governed by a BSD-style license that can be
     1.6 +// found in the LICENSE file.
     1.7 +
     1.8 +#ifndef BASE_TASK_RUNNER_H_
     1.9 +#define BASE_TASK_RUNNER_H_
    1.10 +
    1.11 +#include "base/base_export.h"
    1.12 +#include "base/basictypes.h"
    1.13 +#include "base/callback_forward.h"
    1.14 +#include "base/memory/ref_counted.h"
    1.15 +#include "base/time/time.h"
    1.16 +
    1.17 +namespace tracked_objects {
    1.18 +class Location;
    1.19 +} // namespace tracked_objects
    1.20 +
    1.21 +namespace base {
    1.22 +
    1.23 +struct TaskRunnerTraits;
    1.24 +
    1.25 +// A TaskRunner is an object that runs posted tasks (in the form of
    1.26 +// Closure objects).  The TaskRunner interface provides a way of
    1.27 +// decoupling task posting from the mechanics of how each task will be
    1.28 +// run.  TaskRunner provides very weak guarantees as to how posted
    1.29 +// tasks are run (or if they're run at all).  In particular, it only
    1.30 +// guarantees:
    1.31 +//
    1.32 +//   - Posting a task will not run it synchronously.  That is, no
    1.33 +//     Post*Task method will call task.Run() directly.
    1.34 +//
    1.35 +//   - Increasing the delay can only delay when the task gets run.
    1.36 +//     That is, increasing the delay may not affect when the task gets
    1.37 +//     run, or it could make it run later than it normally would, but
    1.38 +//     it won't make it run earlier than it normally would.
    1.39 +//
    1.40 +// TaskRunner does not guarantee the order in which posted tasks are
    1.41 +// run, whether tasks overlap, or whether they're run on a particular
    1.42 +// thread.  Also it does not guarantee a memory model for shared data
    1.43 +// between tasks.  (In other words, you should use your own
    1.44 +// synchronization/locking primitives if you need to share data
    1.45 +// between tasks.)
    1.46 +//
    1.47 +// Implementations of TaskRunner should be thread-safe in that all
    1.48 +// methods must be safe to call on any thread.  Ownership semantics
    1.49 +// for TaskRunners are in general not clear, which is why the
    1.50 +// interface itself is RefCountedThreadSafe.
    1.51 +//
    1.52 +// Some theoretical implementations of TaskRunner:
    1.53 +//
    1.54 +//   - A TaskRunner that uses a thread pool to run posted tasks.
    1.55 +//
    1.56 +//   - A TaskRunner that, for each task, spawns a non-joinable thread
    1.57 +//     to run that task and immediately quit.
    1.58 +//
    1.59 +//   - A TaskRunner that stores the list of posted tasks and has a
    1.60 +//     method Run() that runs each runnable task in random order.
    1.61 +class BASE_EXPORT TaskRunner
    1.62 +    : public RefCountedThreadSafe<TaskRunner, TaskRunnerTraits> {
    1.63 + public:
    1.64 +  // Posts the given task to be run.  Returns true if the task may be
    1.65 +  // run at some point in the future, and false if the task definitely
    1.66 +  // will not be run.
    1.67 +  //
    1.68 +  // Equivalent to PostDelayedTask(from_here, task, 0).
    1.69 +  bool PostTask(const tracked_objects::Location& from_here,
    1.70 +                const Closure& task);
    1.71 +
    1.72 +  // Like PostTask, but tries to run the posted task only after
    1.73 +  // |delay_ms| has passed.
    1.74 +  //
    1.75 +  // It is valid for an implementation to ignore |delay_ms|; that is,
    1.76 +  // to have PostDelayedTask behave the same as PostTask.
    1.77 +  virtual bool PostDelayedTask(const tracked_objects::Location& from_here,
    1.78 +                               const Closure& task,
    1.79 +                               base::TimeDelta delay) = 0;
    1.80 +
    1.81 +  // Returns true if the current thread is a thread on which a task
    1.82 +  // may be run, and false if no task will be run on the current
    1.83 +  // thread.
    1.84 +  //
    1.85 +  // It is valid for an implementation to always return true, or in
    1.86 +  // general to use 'true' as a default value.
    1.87 +  virtual bool RunsTasksOnCurrentThread() const = 0;
    1.88 +
    1.89 +  // Posts |task| on the current TaskRunner.  On completion, |reply|
    1.90 +  // is posted to the thread that called PostTaskAndReply().  Both
    1.91 +  // |task| and |reply| are guaranteed to be deleted on the thread
    1.92 +  // from which PostTaskAndReply() is invoked.  This allows objects
    1.93 +  // that must be deleted on the originating thread to be bound into
    1.94 +  // the |task| and |reply| Closures.  In particular, it can be useful
    1.95 +  // to use WeakPtr<> in the |reply| Closure so that the reply
    1.96 +  // operation can be canceled. See the following pseudo-code:
    1.97 +  //
    1.98 +  // class DataBuffer : public RefCountedThreadSafe<DataBuffer> {
    1.99 +  //  public:
   1.100 +  //   // Called to add data into a buffer.
   1.101 +  //   void AddData(void* buf, size_t length);
   1.102 +  //   ...
   1.103 +  // };
   1.104 +  //
   1.105 +  //
   1.106 +  // class DataLoader : public SupportsWeakPtr<DataLoader> {
   1.107 +  //  public:
   1.108 +  //    void GetData() {
   1.109 +  //      scoped_refptr<DataBuffer> buffer = new DataBuffer();
   1.110 +  //      target_thread_.message_loop_proxy()->PostTaskAndReply(
   1.111 +  //          FROM_HERE,
   1.112 +  //          base::Bind(&DataBuffer::AddData, buffer),
   1.113 +  //          base::Bind(&DataLoader::OnDataReceived, AsWeakPtr(), buffer));
   1.114 +  //    }
   1.115 +  //
   1.116 +  //  private:
   1.117 +  //    void OnDataReceived(scoped_refptr<DataBuffer> buffer) {
   1.118 +  //      // Do something with buffer.
   1.119 +  //    }
   1.120 +  // };
   1.121 +  //
   1.122 +  //
   1.123 +  // Things to notice:
   1.124 +  //   * Results of |task| are shared with |reply| by binding a shared argument
   1.125 +  //     (a DataBuffer instance).
   1.126 +  //   * The DataLoader object has no special thread safety.
   1.127 +  //   * The DataLoader object can be deleted while |task| is still running,
   1.128 +  //     and the reply will cancel itself safely because it is bound to a
   1.129 +  //     WeakPtr<>.
   1.130 +  bool PostTaskAndReply(const tracked_objects::Location& from_here,
   1.131 +                        const Closure& task,
   1.132 +                        const Closure& reply);
   1.133 +
   1.134 + protected:
   1.135 +  friend struct TaskRunnerTraits;
   1.136 +
   1.137 +  // Only the Windows debug build seems to need this: see
   1.138 +  // http://crbug.com/112250.
   1.139 +  friend class RefCountedThreadSafe<TaskRunner, TaskRunnerTraits>;
   1.140 +
   1.141 +  TaskRunner();
   1.142 +  virtual ~TaskRunner();
   1.143 +
   1.144 +  // Called when this object should be destroyed.  By default simply
   1.145 +  // deletes |this|, but can be overridden to do something else, like
   1.146 +  // delete on a certain thread.
   1.147 +  virtual void OnDestruct() const;
   1.148 +};
   1.149 +
   1.150 +struct BASE_EXPORT TaskRunnerTraits {
   1.151 +  static void Destruct(const TaskRunner* task_runner);
   1.152 +};
   1.153 +
   1.154 +}  // namespace base
   1.155 +
   1.156 +#endif  // BASE_TASK_RUNNER_H_

mercurial