1. 05 Apr, 2017 1 commit
    • tzik's avatar
      Migrate base::TaskRunner from Closure to OnceClosure · 6e42784f
      tzik authored
      After this CL, TaskRunner::PostTask and its family can take OnceClosure
      in addition to Closure.
      
      Most of the changes are mechanical replacement of Closure with OnceClosure
      on TaskRunner family. Others are:
       - Limit CriticalClosure from Closure to OnceClosure as no caller call
         the resulting callback more than once
       - Add several PostTaskAndReplyWithResult overloads for old Callback
         version, for compatibility. (in base/task_scheduler/post_task.h)
       - Update SequencedWorkerPool implementation for OnceClosure.
       - Update task handling code in app_state.mm for OnceClosure, which is
         needed to bring OnceClosure into a ObjC block.
      
      BUG=704027
      CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
      
      Review-Url: https://codereview.chromium.org/2637843002
      Cr-Commit-Position: refs/heads/master@{#462023}
      6e42784f
  2. 29 Mar, 2017 1 commit
    • tzik's avatar
      Pass Callback to TaskRunner by value and consume it on invocation · 070c8ffb
      tzik authored
      This is a preparation CL for http://crrev.com/2637843002, which replaces
      the Callback parameter of TaskRunner::PostTask with OnceCallback.
      This one replaces the passed-by-const-ref Callback parameter of
      TaskRunner::PostTask() with pass-by-value.
      
      With the pass-by-const-ref manner as the old code does, we can't avoid
      leaving a reference to the callback object on the original thread. That
      is, the callback object may be destroyed either on the target thread or
      the original thread. That's problematic when a non-thread-safe object is
      bound to the callback.
      
      Pass-by-value and move() in this CL mitigate the nondeterminism: if the
      caller of TaskRunner::PostTask() passes the callback object as rvalue,
      TaskRunner::PostTask() leaves no reference on the original thread.
      I.e. the reference is not left if the callback is passed directly from
      Bind(), or passed with std::move() as below.
      
        task_runner->PostTask(FROM_HERE, base::Bind(&Foo));
      
        base::Closure cb = base::Bind(&Foo);
        task_runner->PostTask(FROM_HERE, std::move(cb));
      
      Otherwise, if the caller passes the callback as lvalue, a reference to
      the callback is left on the original thread as we do in the previous code.
      I.e. a reference is left if the callback is passed from other non-temporary
      variable.
      
        base::Closure cb = base::Bind(&Foo);
        task_runner->PostTask(FROM_HERE, cb);
      
      This is less controversial part of http://crrev.com/2637843002. This CL
      is mainly to land it incrementally.
      
      TBR=shrike@chromium.org
      BUG=704027
      CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
      
      Review-Url: https://codereview.chromium.org/2726523002
      Cr-Commit-Position: refs/heads/master@{#460288}
      070c8ffb
  3. 02 Mar, 2017 2 commits
    • gab's avatar
      Fix lack of lock in MTTR::TakePendingTasks() and add a few more safety checks. · eebea688
      gab authored
      BUG=587199
      
      Review-Url: https://codereview.chromium.org/2720903002
      Cr-Commit-Position: refs/heads/master@{#454159}
      eebea688
    • gab's avatar
      Introduce ThreadTaskRunnerHandle::OverrideForTesting and TestMockTimeTaskRunner::ScopedContext. · a6f72328
      gab authored
      Will be used to provide proper ThreadTaskRunnerHandle context in unit
      tests when multiple test task runners share the main thread.
      
      TestMockTimeTaskRunner::ScopedContext as discussed @
      https://groups.google.com/a/chromium.org/d/msg/chromium-dev/kSIe9p5ZYGM/koFefJmNCAAJ
      
      This cleans up HttpServerPropertiesManagerTest to actually run code
      in the scope of the task runners the impl expects it to (it would
      previously pass because TestMockTimeTaskRunner::RunsOnCurrentThread()
      is looser than it should be -- merely checks thread id, not runner context).
      This is a prerequisite for https://codereview.chromium.org/2491613004/
      as it otherwise breaks per its tasks posting to unexpected tasks runners
      (i.e. the current ThreadTaskRunnerHandle() which was the underlying unmocked
      MessageLoop in these tests).
      
      Further addressed in those tests:
       - No longer need to use MessageLoop/RunLoop
         - Which removes need for completion Closure on the updates.
       - Exposes timer timings to fast-forward by the right timing instead of
         FastForwardUntilNoTasksRemain() -- test could use some more cleanup in that
         regard but that's a first pass of mandatory sites.
      
      Also addressed in this CL:
       - ServerBackedStateKeysBrokerTest.Refresh, RecentTabHelperTest, AffiliatedMatchHelperTest, and SyncStoppedReporterTest
        - Now mocks main thread runner directly, removes need for test-only SetTaskRunner() methods :).
         (having a custom TaskRunner was causing things like observers to post to the wrong task runner per this CL's
          ThreadTaskRunnerHandle override in its deferred initialization).
       - AsyncDocumentSubresourceFilterTest, WallPaperColorCalculatorTest and PostAndReplyImplTest
        - Unfortunately those tests were fine but as documented in thread_task_runner_handle.cc:
          supporting SequencedTaskRunnerHandle overrides from main thread would be overkill for
          now... so they were tweaked to avoid doing that.
        - Also, upcoming base::test::ScopedTaskEnvironment makes all of this an implementation detail anyways:
          draft @ https://docs.google.com/document/d/1QabRo8c7D9LsYY3cEcaPQbOCLo8Tu-6VLykYXyl3Pkk/edit
      
      BUG=587199
      
      Review-Url: https://codereview.chromium.org/2657013002
      Cr-Commit-Position: refs/heads/master@{#454127}
      a6f72328
  4. 27 Jan, 2017 1 commit
  5. 19 Nov, 2016 1 commit
  6. 13 Sep, 2016 1 commit
    • ricea's avatar
      Re-write many calls to WrapUnique() with MakeUnique() · ec7c3997
      ricea authored
      A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
      MakeUnique<Foo>(...). See the thread at
      https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
      for background.
      
      To avoid requiring too many manual fixups, the change skips some cases that are
      frequently problematic. In particular, in methods named Foo::Method() it will
      not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
      Foo::Method() may be accessing an internal constructor of Foo.
      
      Cases where MakeUnique<NestedClass>(...) is called within a method of
      OuterClass are common but hard to detect automatically, so have been fixed-up
      manually.
      
      The only types of manual fix ups applied are:
      1) Revert MakeUnique back to WrapUnique
      2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
         correctly)
      3) Add base:: namespace qualifier where missing.
      
      WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
      change behaviour if Foo does not have a user-defined constructor. For example,
      WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
      creates an integer initialised to 0.
      
      git cl format has been been run over the CL. Spot-checking has uncovered no
      cases of mis-formatting.
      
        BUG=637812
      
      Review-Url: https://codereview.chromium.org/2258713003
      Cr-Commit-Position: refs/heads/master@{#418167}
      ec7c3997
  7. 04 Apr, 2016 1 commit
  8. 15 Jan, 2016 1 commit
  9. 24 Dec, 2015 1 commit
  10. 02 Apr, 2015 1 commit
  11. 18 Mar, 2015 1 commit
    • binjin's avatar
      Initial RemoteCommandService · efa8017c
      binjin authored
      This CL adds initial implementation of RemoteCommandService. RemoteCommandService contains a RemoteCommandsQueue and will interacts with DMServer to fetch and run commands in sequence. Protocol modification is made to protobuf as well.
      
      BUG=None
      
      Review URL: https://codereview.chromium.org/879233003
      
      Cr-Commit-Position: refs/heads/master@{#321103}
      efa8017c
  12. 10 Mar, 2015 1 commit
  13. 27 Feb, 2015 1 commit
  14. 16 Feb, 2015 1 commit
  15. 13 Feb, 2015 1 commit
    • engedy's avatar
      Add support in TestMockTimeTaskRunner for vending mock Time values and mock Clocks. · 5cae03fa
      engedy authored
      Previously, TestMockTimeTaskRunner had only supported vending out TimeTicks and TickClocks. Now it supports mock Time and mock Clocks too (they start at the Unix epoch).
      
      This CL also shortens the names of the methods that vend the current time and time ticks to Now() and NowTicks(), respectively; removes using the "base" namespace prefix inside the "base" namespace; and provides a clean implementation for FastForwardUntilNoTasksRemain() instead of a hacky solution.
      
      BUG=329911
      TBR=phajdan.jr@chromium.org  # OOO.
      
      Review URL: https://codereview.chromium.org/899863002
      
      Cr-Commit-Position: refs/heads/master@{#316219}
      5cae03fa
  16. 02 Feb, 2015 1 commit
  17. 13 Jan, 2015 1 commit
  18. 12 Jan, 2015 2 commits