Threads can race to be the first one to calculate the empty path ref's bounds.
authorcommit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81>
Wed, 2 Oct 2013 16:42:58 +0000 (16:42 +0000)
committercommit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81>
Wed, 2 Oct 2013 16:42:58 +0000 (16:42 +0000)
commit80390ec0f5b5a07b7b3510a64a6efb5c9058a937
tree96444b24b5b057112d5eb78f2673b9ab524f660b
parent03087072483378a43f7b3f7a47944614187275eb
Threads can race to be the first one to calculate the empty path ref's bounds.
To dodge the problem, call computeBounds when creating the global empty path
ref.

There's still another race here, which is that we can race to create the empty
path ref in the first place.  As written we can conceivably allocate an
arbitrary number of empty path refs, one of which ends up pointed to by the
global variable at the end.

I've punted on fixing this for now because 1) tsan has not complained yet; 2) I
think it can be fixed by the same approach as we can fix the memsets in
25415003, so I want to wait to see how that review goes
first.

BUG=
R=reed@google.com, robertphillips@google.com

Author: mtklein@google.com

Review URL: https://codereview.chromium.org/25745003

git-svn-id: http://skia.googlecode.com/svn/trunk@11576 2bbb7eff-a529-9590-31e7-b0007b416f81
include/core/SkPathRef.h