Don't peek messages in the MessagePumpForUI class when we receive our kMsgHaveWork message.

Don't peek messages in the MessagePumpForUI class when we receive our kMsgHaveWork message.

Currently the MessagePumpForUI class peeks Windows messages when we receive the kMsgHaveWork message in
our main message loop and in nested modal loops. This is because the posted message starves the message loop
of input and other lower priority messages. While this is ok for the main message loop our peeking and dispatching
messages in nested loops is wrong and violates the silent contract where in the nested loop should be the one peeking
and dispatching messages.

To fix this the approach we are taking is to create a worker thread which uses a waitable timer of 3 ms which posts
the kMsgHaveWork message to the main loop when the timer fires. As a result we can safely delete all the code
in the MessagePumpForUI::ScheduleWork function and simplify the ProcessPumpReplacementMessage function.

The MessagePumpForUI::ScheduleWork function now checks the delay for the task at the head of the queue
If it is 0 then we post the message right away as it is a regular task. Added functions (GetNewlyAddedTaskDelay) to the MessagePump::Delegate class and the IncomingTaskQueue for this.

The other change here is to change the GPU process to use the IO message pump by default and use the UI pump only
if we are using opengl. Reason being this patch causes a delay in processing tasks due to the worker thread which
causes tests like webgl_conformance to fail. We will continue working on addressing this over the coming days.

BUG=492837
R=cpu

Committed: https://crrev.com/b8e126c8b532b1327f38afe2bdf59aa5ff933971
Cr-Commit-Position: refs/heads/master@{#333572}

[cpu_(ooo_6.6-7.5), 2015-05-28 22:45:12]

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:448: if (ret == WAIT_OBJECT_0) {
instead of using exit_ui_worker_thread_ rather use WAIT_IO_COMPLETION return
code. ShutdownWorkerThread can then do nothing.

This way you don't have to deal with synchronization issues.

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:477: CHECK(instance);
you can remove the 477 check

[cpu_(ooo_6.6-7.5), 2015-05-28 22:45:51]

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:95: ui_worker_thread_.reset(new
base::Thread("UI Pump Worker thread"));
can we do this only when we are nested?

[ananta, 2015-05-29 00:51:29]

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:95: ui_worker_thread_.reset(new
base::Thread("UI Pump Worker thread"));
On 2015/05/28 22:45:51, cpu wrote:
> can we do this only when we are nested?

We only do this now when we have tasks. Difficult to identify when we are in a
modal loop. A msg filter might work but it is too intrusive.

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:448: if (ret == WAIT_OBJECT_0) {
On 2015/05/28 22:45:12, cpu wrote:
> instead of using exit_ui_worker_thread_ rather use WAIT_IO_COMPLETION return
> code. ShutdownWorkerThread can then do nothing.
> 
> This way you don't have to deal with synchronization issues.

Done.

https://codereview.chromium.org/1156503005/diff/20001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:477: CHECK(instance);
On 2015/05/28 22:45:12, cpu wrote:
> you can remove the 477 check

Done.

[jbauman, 2015-05-29 22:47:44]

jbauman@chromium.org changed reviewers:
+ jbauman@chromium.org

[jbauman, 2015-05-29 22:47:44]

Seems nice, though I'm a bit worried that processing 1 task every 3 ms might not
be enough in some circumstances. Also, hopefully a WaitableTimer set to a 3ms
period won't actually wake up some thread or something every 3ms if it's not
reset.

Also, I'm curious if CreateTimerQueue would work to avoid creating a separate
thread.

[jbauman, 2015-05-29 22:47:56]

jbauman@chromium.org changed reviewers:
- jbauman@chromium.org

[cpu_(ooo_6.6-7.5), 2015-06-02 00:17:27]

https://codereview.chromium.org/1156503005/diff/40001/base/message_loop/messa...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/40001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:448: HANDLE objects[] =
{ui_worker_thread_signal_.handle(), timer.Get()};
I don't think you need the ui_worker_thread_signal_, use only the timer and use
CancelWaitableTimer or SetWaitableTimer to stop or go.

https://codereview.chromium.org/1156503005/diff/40001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:475: }
the original code seems to reset have_work_ here, see line 119.

reading the original comments 438-444 I am not sure this boolean flag is even
needed.

https://codereview.chromium.org/1156503005/diff/40001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:481: return;
have a comment in 481 explaining why the empty function works.

[jar (doing other things), 2015-06-02 00:35:15]

jar@chromium.org changed reviewers:
+ jar@chromium.org

[jar (doing other things), 2015-06-02 00:35:16]

Drive-by commentary (invited by cpu).

I suspect that this approach will put a hard limit on the rate at which these
tickler messages can be posted, and hence limit the rate at which Chrome Tasks
(both delayed, and non-delayed) can be processed.

The currently code cleverly(?) posts a new ticker every time it processes an old
tickler.  This means that when the windows message queue is busy, the tasks
(induced by processing by a ticker) will become infrequent (stealing minimal CPU
cycles from the native loop).  It also means that when the CPU is not busy (in
this nested message loop), that the tickler messages can be processed basically
as fast as the windows loop can cycle through them.

When a fixed delay (3ms?) is added, this means that the messages (Chrome tasks?)
can never be processed faster than about 300Hz.  When the system timer is not
set to a higher rate (sitting at 15ms+), the attempted 3ms delay probably gets
rounded up, and the delay then probably limits processing to about the Chrome
Task processing rate to 60Hz (as I recall, only one task is processed per
tickler!).

The current code allows fast machines to run quickly, while servicing the native
message loop.   This newer code may significantly degrade performance on faster
machines.

YMMV.

[ananta, 2015-06-02 00:58:23]

On 2015/06/02 00:35:16, jar (doing other things) wrote:
> Drive-by commentary (invited by cpu).
> 
> I suspect that this approach will put a hard limit on the rate at which these
> tickler messages can be posted, and hence limit the rate at which Chrome Tasks
> (both delayed, and non-delayed) can be processed.
> 
> The currently code cleverly(?) posts a new ticker every time it processes an
old
> tickler.  This means that when the windows message queue is busy, the tasks
> (induced by processing by a ticker) will become infrequent (stealing minimal
CPU
> cycles from the native loop).  It also means that when the CPU is not busy (in
> this nested message loop), that the tickler messages can be processed
basically
> as fast as the windows loop can cycle through them.
> 
> When a fixed delay (3ms?) is added, this means that the messages (Chrome
tasks?)
> can never be processed faster than about 300Hz.  When the system timer is not
> set to a higher rate (sitting at 15ms+), the attempted 3ms delay probably gets
> rounded up, and the delay then probably limits processing to about the Chrome
> Task processing rate to 60Hz (as I recall, only one task is processed per
> tickler!).
> 
> The current code allows fast machines to run quickly, while servicing the
native
> message loop.   This newer code may significantly degrade performance on
faster
> machines.
> 
> YMMV.

When the system timer is not set to a higher rate then it means that we don't
have any high priority
tasks waiting to be serviced. If we have such tasks then timebeginperiod should
take care of setting
the resolution of the system timer to 3 or 4 ms depending on whether we have AC
or battery power.
Our message loop violates the basic rule of message loops which is to defer the
peeking of windows message
to the enclosed modal loop if any. The posted message we use for processing
tasks interferes with the basic
windows message priority and hence necessiates our peeking in the nested loop.
One wrong for another wrong.

We can land this as a trial to see how this pans out and revert if it breaks
stuff.

[jar (doing other things), 2015-06-02 02:41:06]

On 2015/06/02 00:58:23, ananta wrote:
> On 2015/06/02 00:35:16, jar (doing other things) wrote:
> > Drive-by commentary (invited by cpu).
> > 
> > I suspect that this approach will put a hard limit on the rate at which
these
> > tickler messages can be posted, and hence limit the rate at which Chrome
Tasks
> > (both delayed, and non-delayed) can be processed.
> > 
> > The currently code cleverly(?) posts a new ticker every time it processes an
> old
> > tickler.  This means that when the windows message queue is busy, the tasks
> > (induced by processing by a ticker) will become infrequent (stealing minimal
> CPU
> > cycles from the native loop).  It also means that when the CPU is not busy
(in
> > this nested message loop), that the tickler messages can be processed
> basically
> > as fast as the windows loop can cycle through them.
> > 
> > When a fixed delay (3ms?) is added, this means that the messages (Chrome
> tasks?)
> > can never be processed faster than about 300Hz.  When the system timer is
not
> > set to a higher rate (sitting at 15ms+), the attempted 3ms delay probably
gets
> > rounded up, and the delay then probably limits processing to about the
Chrome
> > Task processing rate to 60Hz (as I recall, only one task is processed per
> > tickler!).
> > 
> > The current code allows fast machines to run quickly, while servicing the
> native
> > message loop.   This newer code may significantly degrade performance on
> faster
> > machines.
> > 
> > YMMV.
> 
> When the system timer is not set to a higher rate then it means that we don't
> have any high priority
> tasks waiting to be serviced. If we have such tasks then timebeginperiod
should
> take care of setting
> the resolution of the system timer to 3 or 4 ms depending on whether we have
AC
> or battery power.
> Our message loop violates the basic rule of message loops which is to defer
the
> peeking of windows message
> to the enclosed modal loop if any. The posted message we use for processing
> tasks interferes with the basic
> windows message priority and hence necessiates our peeking in the nested loop.
> One wrong for another wrong.
> 
> We can land this as a trial to see how this pans out and revert if it breaks
> stuff.

The OS System timer rate is only increased if there are DelayedTasks with small
delays pending (at least that is the way it is supposed to work).

When non-delayed Chrome tasks are posted, the presumption is that they will be
processed ASAP, and the system timer interval is not modified. This change will
seemingly replace the contracted "ASAP" to "no faster than 60 tasks per second"
(while we have a nested system message loop active).

[ananta, 2015-06-02 02:45:24]

On 2015/06/02 02:41:06, jar (doing other things) wrote:
> On 2015/06/02 00:58:23, ananta wrote:
> > On 2015/06/02 00:35:16, jar (doing other things) wrote:
> > > Drive-by commentary (invited by cpu).
> > > 
> > > I suspect that this approach will put a hard limit on the rate at which
> these
> > > tickler messages can be posted, and hence limit the rate at which Chrome
> Tasks
> > > (both delayed, and non-delayed) can be processed.
> > > 
> > > The currently code cleverly(?) posts a new ticker every time it processes
an
> > old
> > > tickler.  This means that when the windows message queue is busy, the
tasks
> > > (induced by processing by a ticker) will become infrequent (stealing
minimal
> > CPU
> > > cycles from the native loop).  It also means that when the CPU is not busy
> (in
> > > this nested message loop), that the tickler messages can be processed
> > basically
> > > as fast as the windows loop can cycle through them.
> > > 
> > > When a fixed delay (3ms?) is added, this means that the messages (Chrome
> > tasks?)
> > > can never be processed faster than about 300Hz.  When the system timer is
> not
> > > set to a higher rate (sitting at 15ms+), the attempted 3ms delay probably
> gets
> > > rounded up, and the delay then probably limits processing to about the
> Chrome
> > > Task processing rate to 60Hz (as I recall, only one task is processed per
> > > tickler!).
> > > 
> > > The current code allows fast machines to run quickly, while servicing the
> > native
> > > message loop.   This newer code may significantly degrade performance on
> > faster
> > > machines.
> > > 
> > > YMMV.
> > 
> > When the system timer is not set to a higher rate then it means that we
don't
> > have any high priority
> > tasks waiting to be serviced. If we have such tasks then timebeginperiod
> should
> > take care of setting
> > the resolution of the system timer to 3 or 4 ms depending on whether we have
> AC
> > or battery power.
> > Our message loop violates the basic rule of message loops which is to defer
> the
> > peeking of windows message
> > to the enclosed modal loop if any. The posted message we use for processing
> > tasks interferes with the basic
> > windows message priority and hence necessiates our peeking in the nested
loop.
> > One wrong for another wrong.
> > 
> > We can land this as a trial to see how this pans out and revert if it breaks
> > stuff.
> 
> The OS System timer rate is only increased if there are DelayedTasks with
small
> delays pending (at least that is the way it is supposed to work).
> 
> When non-delayed Chrome tasks are posted, the presumption is that they will be
> processed ASAP, and the system timer interval is not modified. This change
will
> seemingly replace the contracted "ASAP" to "no faster than 60 tasks per
second"
> (while we have a nested system message loop active).

Yes. That is the intention here. We will work towards a good approach in the
coming days with a complete rewrite of
the message ui pump on Windows if needed. That is the last resort.

[cpu_(ooo_6.6-7.5), 2015-06-02 19:34:19]

I made another comment in PS3 about the need for the event, let me know.

[cpu_(ooo_6.6-7.5), 2015-06-03 00:57:11]

lgtm

To be fair, the timer fire rate is something that seems we are not addressing
properly as noted by jar@ and jbauman@ but I consider this a "exploratory"
approach, certainly needs to be refined or reverted.

But I will like to see the effects of the current change on the bots and get a
canary with this.

https://codereview.chromium.org/1156503005/diff/100001/base/message_loop/mess...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/100001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:101: base::Unretained(this)));
indent in 101 looks funny

https://codereview.chromium.org/1156503005/diff/100001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:117: // 3 milliseconds.
make a full sentence, like "set the timer to fire every 3ms." with maybe a
sentence that has the caveat of that the actual fire rate depends on
timeBeginPeriod() being called.

[ananta, 2015-06-03 01:27:30]

https://codereview.chromium.org/1156503005/diff/40001/base/message_loop/messa...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/40001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:448: HANDLE objects[] =
{ui_worker_thread_signal_.handle(), timer.Get()};
On 2015/06/02 00:17:27, cpu wrote:
> I don't think you need the ui_worker_thread_signal_, use only the timer and
use
> CancelWaitableTimer or SetWaitableTimer to stop or go.

We are using the ui_worker_thread_signal_ to avoid processing the timer when we
don't have tasks. The ui_worker_thread_signal_ event is signaled when tasks are
added to the queue in ScheduleEvent

https://codereview.chromium.org/1156503005/diff/40001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:475: }
On 2015/06/02 00:17:27, cpu wrote:
> the original code seems to reset have_work_ here, see line 119.
> 
> reading the original comments 438-444 I am not sure this boolean flag is even
> needed.

Removed the check for have_work in this function. Will look into removing that
variable in a future patch

https://codereview.chromium.org/1156503005/diff/40001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:481: return;
On 2015/06/02 00:17:27, cpu wrote:
> have a comment in 481 explaining why the empty function works.

Done.

https://codereview.chromium.org/1156503005/diff/100001/base/message_loop/mess...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/100001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:101: base::Unretained(this)));
On 2015/06/03 00:57:11, cpu wrote:
> indent in 101 looks funny

Done.

https://codereview.chromium.org/1156503005/diff/100001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:117: // 3 milliseconds.
On 2015/06/03 00:57:11, cpu wrote:
> make a full sentence, like "set the timer to fire every 3ms." with maybe a
> sentence that has the caveat of that the actual fire rate depends on
> timeBeginPeriod() being called.

Done.

[ananta, 2015-06-04 02:48:31]

ananta@chromium.org changed reviewers:
+ geofflang@chromium.org, kbr@chromium.org

[Ken Russell (switch to Gerrit), 2015-06-04 21:36:56]

gpu_main.cc LGTM. Would be good to get feedback from geofflang@ too.

[Geoff Lang, 2015-06-05 13:40:21]

lgtm

[Geoff Lang, 2015-06-05 13:40:35]

https://codereview.chromium.org/1156503005/diff/140001/content/gpu/gpu_main.cc
File content/gpu/gpu_main.cc (right):

https://codereview.chromium.org/1156503005/diff/140001/content/gpu/gpu_main.c...
content/gpu/gpu_main.cc:166: // TODO(ananta) : Recent changes to the UI message
pump class on Windows
ANGLE may be able to avoid creating a child window, I'm working on that now.
Chrome's own desktop GL renderer will likely be deprecated on Windows in the
next few months if ANGLE's GL renderer turns out well.

[ananta, 2015-06-06 00:24:18]

cpu, please take a peek at the latest patch. I added code to process posted
tasks with 0 delays immediately rather than going through the worker thread.

Thanks

[scottmg, 2015-06-08 21:43:30]

scottmg@chromium.org changed reviewers:
+ scottmg@chromium.org

[scottmg, 2015-06-08 21:43:31]

(temporary stand in for cpu by request)

I don't really understand the finer details, but seems OK.

https://codereview.chromium.org/1156503005/diff/160001/base/message_loop/mess...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/160001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:127: due_time.QuadPart = -30000;
How did we pick 3?

https://codereview.chromium.org/1156503005/diff/160001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:462: PostWorkMessage();
Is it possible for this only to runwhen SetNestableTasksAllowed or
set_os_modal_loop or whatever? Or does it already do that somehow?

[ananta, 2015-06-08 21:46:55]

https://codereview.chromium.org/1156503005/diff/160001/base/message_loop/mess...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/160001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:127: due_time.QuadPart = -30000;
On 2015/06/08 21:43:31, scottmg wrote:
> How did we pick 3?

That was a consensus number based on the fact that the fastest our timers run
are 3 milliseconds for AC and 4 for battery

https://codereview.chromium.org/1156503005/diff/160001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:462: PostWorkMessage();
On 2015/06/08 21:43:31, scottmg wrote:
> Is it possible for this only to runwhen SetNestableTasksAllowed or
> set_os_modal_loop or whatever? Or does it already do that somehow?

It does not do that. Tricky to detect modal loops anyways. The only consumer of
set_os_modal loop is npapi plugins. We decided with the thread approach to avoid
our main pump peeking for other messages when we see our wake up message

[scottmg, 2015-06-08 21:50:56]

ok, lgtm

[ananta, 2015-06-08 22:28:08]

The CQ bit was checked by ananta@chromium.org

[ananta, 2015-06-08 22:28:08]

The patchset sent to the CQ was uploaded after l-g-t-m from cpu@chromium.org,
kbr@chromium.org, geofflang@chromium.org
Link to the patchset: https://codereview.chromium.org/1156503005/#ps160001
(title: "Provide a way to process posted tasks quicker")

[commit-bot: I haz the power, 2015-06-08 22:28:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1156503005/160001

[ananta, 2015-06-08 23:08:53]

The CQ bit was unchecked by ananta@chromium.org

[scottmg, 2015-06-09 00:15:29]

https://codereview.chromium.org/1156503005/diff/180001/base/message_loop/mess...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/180001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:126: // timer is dependent on
timeBeginPeriod being called.
mention that this is one-shot here.

https://codereview.chromium.org/1156503005/diff/180001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:466: due_time.QuadPart = -30000;
make this a constant, or better a helper function now that it's in two places.

[ananta, 2015-06-09 00:27:54]

https://codereview.chromium.org/1156503005/diff/180001/base/message_loop/mess...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1156503005/diff/180001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:126: // timer is dependent on
timeBeginPeriod being called.
On 2015/06/09 00:15:29, scottmg wrote:
> mention that this is one-shot here.

Done.

https://codereview.chromium.org/1156503005/diff/180001/base/message_loop/mess...
base/message_loop/message_pump_win.cc:466: due_time.QuadPart = -30000;
On 2015/06/09 00:15:29, scottmg wrote:
> make this a constant, or better a helper function now that it's in two places.

Done.

[scottmg, 2015-06-09 16:22:42]

lgtm

https://codereview.chromium.org/1156503005/diff/200001/base/message_loop/mess...
File base/message_loop/message_pump_win.h (right):

https://codereview.chromium.org/1156503005/diff/200001/base/message_loop/mess...
base/message_loop/message_pump_win.h:158: void SetWakeupTimer(int64 delay);
nit; "delay_ms" (and in the .cc) would be better since the units are not
necessarily clear

[ananta, 2015-06-09 18:25:44]

https://codereview.chromium.org/1156503005/diff/200001/base/message_loop/mess...
File base/message_loop/message_pump_win.h (right):

https://codereview.chromium.org/1156503005/diff/200001/base/message_loop/mess...
base/message_loop/message_pump_win.h:158: void SetWakeupTimer(int64 delay);
On 2015/06/09 16:22:42, scottmg wrote:
> nit; "delay_ms" (and in the .cc) would be better since the units are not
> necessarily clear

Done.

[ananta, 2015-06-09 18:25:56]

The CQ bit was checked by ananta@chromium.org

[ananta, 2015-06-09 18:25:57]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org,
cpu@chromium.org, geofflang@chromium.org, scottmg@chromium.org
Link to the patchset: https://codereview.chromium.org/1156503005/#ps220001
(title: "Rename the delay parameter to delay_ms to clear things up")

[commit-bot: I haz the power, 2015-06-09 18:26:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1156503005/220001

[ananta, 2015-06-09 18:34:12]

The CQ bit was unchecked by ananta@chromium.org

[ananta, 2015-06-09 19:20:56]

The CQ bit was checked by ananta@chromium.org

[ananta, 2015-06-09 19:20:57]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org,
cpu@chromium.org, geofflang@chromium.org, scottmg@chromium.org
Link to the patchset: https://codereview.chromium.org/1156503005/#ps240001
(title: "Fix build error")

[commit-bot: I haz the power, 2015-06-09 19:21:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1156503005/240001

[commit-bot: I haz the power, 2015-06-09 21:02:20]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2015-06-09 21:03:34]

Patchset 13 (id:??) landed as
https://crrev.com/b8e126c8b532b1327f38afe2bdf59aa5ff933971
Cr-Commit-Position: refs/heads/master@{#333572}

[kjellander_chromium, 2015-06-10 07:53:25]

A revert of this CL (patchset #13 id:240001) has been created in
https://codereview.chromium.org/1163423006/ by kjellander@chromium.org.

The reason for reverting is: I suspect this CL breaks Windows 8
content_unittests, as it's listed both in 
https://build.chromium.org/p/chromium.fyi/builders/Win8%20Tests%20%281%29/bui...
and our WebRTC-specific waterfall:
https://build.chromium.org/p/chromium.webrtc/builders/Win8%20Tester/builds/14164

I'll try to reland if it turns out not to solve the breakage..