Support "await a stable state" and "provide a stable state"

Source/core/html/StableState.cpp

Index: Source/core/html/StableState.cpp
diff --git a/Source/core/html/StableState.cpp b/Source/core/html/StableState.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..26b071da48bb11296d43a51b4656dbccc95286ed
--- /dev/null
+++ b/Source/core/html/StableState.cpp
@@ -0,0 +1,54 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "config.h"
+#include "core/html/StableState.h"
+
+#include "wtf/HashSet.h"
+#include "wtf/MainThread.h"
+
+namespace WebCore {
+
+typedef HashSet<StableState::Awaiter*> StableStateAwaiters;
+
+static StableStateAwaiters& stableStateAwaiters()
+{
+    DEFINE_STATIC_LOCAL(StableStateAwaiters, stableStateAwaiters, ());
+    return stableStateAwaiters;
+}
+
+static bool isInStableState = false;

[acolwell GONE FROM CHROMIUM, 2014/02/10 22:36:05]

nit: Now that we have more than one piece of state for this, I think the "static
thing" should just be a StableState object and the awaiters and bool be members.

[philipj_slow, 2014/02/17 11:59:24]

Then the call sites would have to say something like
"StableState::instance().provide()", see if you like my alternative approach
with an internal StableStateAwaiters object.

+
+StableState::Awaiter::~Awaiter()
+{
+    ASSERT(isMainThread());
+    stableStateAwaiters().remove(this);
+}
+
+void StableState::await(Awaiter& awaiter)
+{
+    ASSERT(isMainThread());
+    ASSERT(!isInStableState);
+    stableStateAwaiters().add(&awaiter);
+}
+
+void StableState::provide()
+{
+    ASSERT(isMainThread());
+    ASSERT(!isInStableState);
+
+    if (stableStateAwaiters().isEmpty())
+        return;
+
+    isInStableState = true;
+
+    StableStateAwaiters awaiters;
+    awaiters.swap(stableStateAwaiters());

[acolwell GONE FROM CHROMIUM, 2014/02/10 22:36:05]

Can't this cause a use-after-free if executing didAwaitStableState() on one
awaiter causes the destruction of another awaiter?

[philipj_slow, 2014/02/17 11:59:24]

Yes, indeed it can. Since the callbacks aren't run in a deterministic order and
I can't think of a reason to allow it right now, I'll disallow deleting another
awaiter in the callback and assert that it is so.

+    for (StableStateAwaiters::iterator it = awaiters.begin(); it != awaiters.end(); ++it)
+        (*it)->didAwaitStableState();
+
+    isInStableState = false;
+}
+
+} // namespace WebCore