GitLab

When a task posted to TaskScheduler waits on a WaitableEvent, the
pool capacity is automatically incremented after a short delay
(https://cs.chromium.org/chromium/src/base/synchronization/waitable_event_win.cc?l=72&rcl=c60b0bcd6830c32c30128867e55a53f27642df5f and
https://cs.chromium.org/chromium/src/base/synchronization/waitable_event_posix.cc?l=166&rcl=c60b0bcd6830c32c30128867e55a53f27642df5f and
https://cs.chromium.org/chromium/src/base/synchronization/waitable_event_mac.cc?l=115&rcl=c60b0bcd6830c32c30128867e55a53f27642df5f).

This is desirable in production (if a task blocks for a long time,
another thread is created and the number of tasks that are using
the CPU stays constant).

However, it is undesirable when a WaitableEvent is used in
TaskScheduler tests, because it leads to hard to predict changes
of pool capacity.

This CL adds a ScopedClearBlockingObserverForTesting annotation to
all WaitableEvent::Wait that happen in code that tests
SchedulerWorkerPoolImpl, to avoid these hard to predict changes
of pool capacity.

The annotation is not needed when the WaitableEvent::Wait doesn't
happen on a thread managed by SchedulerWorkerPoolImpl, because that
already has no effect on pool capacity.

Bug: 768436
Change-Id: Ie166ca55f914d89c5dd0fe6dad9ae1533e0f6c29
Reviewed-on: https://chromium-review.googlesource.com/1033533Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: François Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554732}