author Kyle Huey <khuey@kylehuey.com>
Tue, 11 Aug 2015 06:10:46 -0700
changeset 289845 a13c1f26e351dd6251da641fe7a9eb53790fc2d0
parent 278996 208891d8e3884b19838a495906697d0363d501a8
child 505383 6f3709b3878117466168c40affa7bca0b60cf75b
permissions -rw-r--r--
Bug 1179909: Refactor stable state handling. r=smaug This is motivated by three separate but related problems: 1. Our concept of recursion depth is broken for things that run from AfterProcessNextEvent observers (e.g. Promises). We decrement the recursionDepth counter before firing observers, so a Promise callback running at the lowest event loop depth has a recursion depth of 0 (whereas a regular nsIRunnable would be 1). This is a problem because it's impossible to distinguish a Promise running after a sync XHR's onreadystatechange handler from a top-level event (since the former runs with depth 2 - 1 = 1, and the latter runs with just 1). 2. The nsIThreadObserver mechanism that is used by a lot of code to run "after" the current event is a poor fit for anything that runs script. First, the order the observers fire in is the order they were added, not anything fixed by spec. Additionally, running script can cause the event loop to spin, which is a big source of pain here (bholley has some nasty bug caused by this). 3. We run Promises from different points in the code for workers and main thread. The latter runs from XPConnect's nsIThreadObserver callbacks, while the former runs from a hardcoded call to run Promises in the worker event loop. What workers do is particularly problematic because it means we can't get the right recursion depth no matter what we do to nsThread. The solve this, this patch does the following: 1. Consolidate some handling of microtasks and all handling of stable state from appshell and WorkerPrivate into CycleCollectedJSRuntime. 2. Make the recursionDepth counter only available to CycleCollectedJSRuntime (and its consumers) and remove it from the nsIThreadInternal and nsIThreadObserver APIs. 3. Adjust the recursionDepth counter so that microtasks run with the recursionDepth of the task they are associated with. 4. Introduce the concept of metastable state to replace appshell's RunBeforeNextEvent. Metastable state is reached after every microtask or task is completed. This provides the semantics that bent and I want for IndexedDB, where transactions autocommit at the end of a microtask and do not "spill" from one microtask into a subsequent microtask. This differs from appshell's RunBeforeNextEvent in two ways: a) It fires between microtasks, which was the motivation for starting this. b) It no longer ensures that we're at the same event loop depth in the native event queue. bent decided we don't care about this. 5. Reorder stable state to happen after microtasks such as Promises, per HTML. Right now we call the regular thread observers, including appshell, before the main thread observer (XPConnect), so stable state tasks happen before microtasks.

/* -*- Mode: c++; tab-width: 2; indent-tabs-mode: nil; -*- */
/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

#ifndef nsBaseAppShell_h__
#define nsBaseAppShell_h__

#include "mozilla/Atomics.h"
#include "nsIAppShell.h"
#include "nsIThreadInternal.h"
#include "nsIObserver.h"
#include "nsIRunnable.h"
#include "nsCOMPtr.h"
#include "nsTArray.h"
#include "prinrval.h"

 * A singleton that manages the UI thread's event queue.  Subclass this class
 * to enable platform-specific event queue support.
class nsBaseAppShell : public nsIAppShell, public nsIThreadObserver,
                       public nsIObserver



  virtual ~nsBaseAppShell();

   * This method is called by subclasses when the app shell singleton is
   * instantiated.
  nsresult Init();

   * Called by subclasses from a native event. See ScheduleNativeEventCallback.
  void NativeEventCallback();

   * Make a decision as to whether or not NativeEventCallback will
   * trigger gecko event processing when there are pending gecko
   * events.
  virtual void DoProcessMoreGeckoEvents();

   * Implemented by subclasses.  Invoke NativeEventCallback from a native
   * event.  This method may be called on any thread.
  virtual void ScheduleNativeEventCallback() = 0;

   * Implemented by subclasses.  Process the next native event.  Only wait for
   * the next native event if mayWait is true.  This method is only called on
   * the main application thread.
   * @param mayWait
   *   If "true", then this method may wait if necessary for the next available
   *   native event.  DispatchNativeEvent may be called to unblock a call to
   *   ProcessNextNativeEvent that is waiting.
   * @return
   *   This method returns "true" if a native event was processed.
  virtual bool ProcessNextNativeEvent(bool mayWait) = 0;

  int32_t mSuspendNativeCount;
  uint32_t mEventloopNestingLevel;

  bool DoProcessNextNativeEvent(bool mayWait);

  bool DispatchDummyEvent(nsIThread* target);

  void IncrementEventloopNestingLevel();
  void DecrementEventloopNestingLevel();

  nsCOMPtr<nsIRunnable> mDummyEvent;
   * mBlockedWait points back to a slot that controls the wait loop in
   * an outer OnProcessNextEvent invocation.  Nested calls always set
   * it to false to unblock an outer loop, since all events may
   * have been consumed by the inner event loop(s).
  bool *mBlockedWait;
  int32_t mFavorPerf;
  mozilla::Atomic<bool> mNativeEventPending;
  PRIntervalTime mStarvationDelay;
  PRIntervalTime mSwitchTime;
  PRIntervalTime mLastNativeEventTime;
  enum EventloopNestingState {
    eEventloopNone,  // top level thread execution
    eEventloopXPCOM, // innermost native event loop is ProcessNextNativeEvent
    eEventloopOther  // innermost native event loop is a native library/plugin etc
  EventloopNestingState mEventloopNestingState;
  bool mRunning;
  bool mExiting;
   * mBlockNativeEvent blocks the appshell from processing native events.
   * It is set to true while a nested native event loop (eEventloopOther)
   * is processing gecko events in NativeEventCallback(), thus queuing up
   * native events until we return to that loop (bug 420148).
   * We force mBlockNativeEvent to false in case handling one of the gecko
   * events spins up a nested XPCOM event loop (eg. modal window) which would
   * otherwise lead to a "deadlock" where native events aren't processed at all.
  bool mBlockNativeEvent;
   * Tracks whether we have processed any gecko events in NativeEventCallback so
   * that we can avoid erroneously entering a blocking loop waiting for gecko
   * events to show up during OnProcessNextEvent.  This is required because on
   * OS X ProcessGeckoEvents may be invoked inside the context of
   * ProcessNextNativeEvent and may result in NativeEventCallback being invoked
   * and in turn invoking NS_ProcessPendingEvents.  Because
   * ProcessNextNativeEvent may be invoked prior to the NS_HasPendingEvents
   * waiting loop, this is the only way to make the loop aware that events may
   * have been processed.
   * This variable is set to false in OnProcessNextEvent prior to the first
   * call to DoProcessNextNativeEvent.  It is set to true by
   * NativeEventCallback after calling NS_ProcessPendingEvents.
  bool mProcessedGeckoEvents;

#endif // nsBaseAppShell_h__