Revert of Turn SkTaskGroups back on.

Revert of Turn SkTaskGroups back on. (patchset #1 id:1 of https://codereview.chromium.org/687263007/)

Reason for revert:
precautionary revert.  may have caused WinXP crashes on Chrome tree: https://code.google.com/p/chromium/issues/detail?id=429207

Original issue's description:
> Turn SkTaskGroups back on.
> 
> Revert "Disable SkTaskGroup in SkMultiPictureDraw temporarily."
> Revert "Revert harder, removing SkTaskGroup.cpp from core temporarily."
> 
> NOTREECHECKS=true
> 
> BUG=skia:
> 
> Committed: https://skia.googlesource.com/skia/+/2100c5ed7a5e5470a04e7af7309d8bd3fc4249f7

TBR=reed@google.com,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Committed: https://skia.googlesource.com/skia/+/e9f7fbfaeed73e36b1b6d0d55dbb2ad4f121e1b7

[mtklein, 2014-10-31 18:29:46]

Created Revert of Turn SkTaskGroups back on.

[commit-bot: I haz the power, 2014-10-31 18:30:10]

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

[commit-bot: I haz the power, 2014-10-31 18:30:25]

Committed patchset #1 (id:1) as e9f7fbfaeed73e36b1b6d0d55dbb2ad4f121e1b7

[reed2, 2014-11-01 19:58:52]

On 2014/10/31 18:30:25, I haz the power (commit-bot) wrote:
> Committed patchset #1 (id:1) as e9f7fbfaeed73e36b1b6d0d55dbb2ad4f121e1b7

Did this revert solve the XP crashes?

[mtklein, 2014-11-01 20:55:58]

On 2014/11/01 19:58:52, reed2 wrote:
> On 2014/10/31 18:30:25, I haz the power (commit-bot) wrote:
> > Committed patchset #1 (id:1) as e9f7fbfaeed73e36b1b6d0d55dbb2ad4f121e1b7
> 
> Did this revert solve the XP crashes?

Pretty sure.  We even accidentally double-checked by re-rolling the original CL
in without the revert, which caused the tests to crash again.

Looks like a Chrome sheriff has stopped our roller.  I'm not sure why.  The
revert is part of our rolls now.  He might just be out of the loop, or this
might mean the SkTaskGroup CL was not the problem, but some other CL in the roll
is.

[mtklein, 2014-11-01 22:15:52]

On 2014/11/01 20:55:58, mtklein wrote:
> On 2014/11/01 19:58:52, reed2 wrote:
> > On 2014/10/31 18:30:25, I haz the power (commit-bot) wrote:
> > > Committed patchset #1 (id:1) as e9f7fbfaeed73e36b1b6d0d55dbb2ad4f121e1b7
> > 
> > Did this revert solve the XP crashes?
> 
> Pretty sure.  We even accidentally double-checked by re-rolling the original
CL
> in without the revert, which caused the tests to crash again.
> 
> Looks like a Chrome sheriff has stopped our roller.  I'm not sure why.  The
> revert is part of our rolls now.  He might just be out of the loop, or this
> might mean the SkTaskGroup CL was not the problem, but some other CL in the
roll
> is.

Actually, I forgot that the first roll that broke the XP bots had only the
SkTaskGroup CL.  Don't see how that can't have been the problem, so given that
and this revert, I think we should be fine now to at least start rolling.

[mtklein, 2014-11-03 21:01:31]

OK, this is definitely the SkTaskGroup CL.  I've reproduced the failures on an
XP machine.  At process startup, a dialog pops up reminding us that condition
variables are not supported on XP/2003, and the code fails to dynamically link.

http://www.chromium.org/developers/lock-and-condition-variable has some pointers
for this problem, but I think I'm probably just going to look for a way to
cleave XP out and force it down a single-threaded path at compile time.

[reed1, 2014-11-03 21:47:57]

On 2014/11/03 21:01:31, mtklein wrote:
> OK, this is definitely the SkTaskGroup CL.  I've reproduced the failures on an
> XP machine.  At process startup, a dialog pops up reminding us that condition
> variables are not supported on XP/2003, and the code fails to dynamically
link.
> 
> http://www.chromium.org/developers/lock-and-condition-variable has some
pointers
> for this problem, but I think I'm probably just going to look for a way to
> cleave XP out and force it down a single-threaded path at compile time.

Great job finding this.

[mtklein, 2014-11-03 21:51:46]

On 2014/11/03 21:47:57, reed1 wrote:
> On 2014/11/03 21:01:31, mtklein wrote:
> > OK, this is definitely the SkTaskGroup CL.  I've reproduced the failures on
an
> > XP machine.  At process startup, a dialog pops up reminding us that
condition
> > variables are not supported on XP/2003, and the code fails to dynamically
> link.
> > 
> > http://www.chromium.org/developers/lock-and-condition-variable has some
> pointers
> > for this problem, but I think I'm probably just going to look for a way to
> > cleave XP out and force it down a single-threaded path at compile time.
> 
> Great job finding this.

These "threads" things better be worth it.

[reed1, 2014-11-03 21:52:47]

On 2014/11/03 21:51:46, mtklein wrote:
> On 2014/11/03 21:47:57, reed1 wrote:
> > On 2014/11/03 21:01:31, mtklein wrote:
> > > OK, this is definitely the SkTaskGroup CL.  I've reproduced the failures
on
> an
> > > XP machine.  At process startup, a dialog pops up reminding us that
> condition
> > > variables are not supported on XP/2003, and the code fails to dynamically
> > link.
> > > 
> > > http://www.chromium.org/developers/lock-and-condition-variable has some
> > pointers
> > > for this problem, but I think I'm probably just going to look for a way to
> > > cleave XP out and force it down a single-threaded path at compile time.
> > 
> > Great job finding this.
> 
> These "threads" things better be worth it.

hehehe