2014-06-30 19:39:45 +04:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
2012-05-21 15:12:37 +04:00
|
|
|
/* 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/. */
|
1999-04-02 13:20:44 +04:00
|
|
|
|
2013-10-23 16:01:24 +04:00
|
|
|
#include "nsThread.h"
|
|
|
|
|
|
|
|
#include "base/message_loop.h"
|
|
|
|
|
|
|
|
// Chromium's logging can sometimes leak through...
|
|
|
|
#ifdef LOG
|
|
|
|
#undef LOG
|
|
|
|
#endif
|
|
|
|
|
2015-05-19 09:31:25 +03:00
|
|
|
#include "mozilla/ReentrantMonitor.h"
|
2013-07-09 06:15:34 +04:00
|
|
|
#include "nsMemoryPressure.h"
|
2006-05-10 21:30:15 +04:00
|
|
|
#include "nsThreadManager.h"
|
|
|
|
#include "nsIClassInfoImpl.h"
|
|
|
|
#include "nsAutoPtr.h"
|
|
|
|
#include "nsCOMPtr.h"
|
2015-09-15 04:24:43 +03:00
|
|
|
#include "nsQueryObject.h"
|
2013-07-12 00:21:45 +04:00
|
|
|
#include "pratom.h"
|
2016-09-14 16:47:32 +03:00
|
|
|
#include "mozilla/CycleCollectedJSContext.h"
|
2015-05-19 21:15:34 +03:00
|
|
|
#include "mozilla/Logging.h"
|
2011-08-06 02:10:50 +04:00
|
|
|
#include "nsIObserverService.h"
|
2011-10-12 21:52:26 +04:00
|
|
|
#include "mozilla/HangMonitor.h"
|
2014-04-09 08:57:52 +04:00
|
|
|
#include "mozilla/IOInterposer.h"
|
2014-08-06 08:43:36 +04:00
|
|
|
#include "mozilla/ipc/MessageChannel.h"
|
2015-04-03 16:52:00 +03:00
|
|
|
#include "mozilla/ipc/BackgroundChild.h"
|
2018-03-06 12:19:19 +03:00
|
|
|
#include "mozilla/Preferences.h"
|
2017-07-29 00:56:49 +03:00
|
|
|
#include "mozilla/Scheduler.h"
|
2017-03-09 23:32:32 +03:00
|
|
|
#include "mozilla/SchedulerGroup.h"
|
2011-08-06 02:10:50 +04:00
|
|
|
#include "mozilla/Services.h"
|
2017-08-21 12:30:22 +03:00
|
|
|
#include "mozilla/SystemGroup.h"
|
2013-07-08 00:23:43 +04:00
|
|
|
#include "nsXPCOMPrivate.h"
|
2014-03-03 09:12:27 +04:00
|
|
|
#include "mozilla/ChaosMode.h"
|
2017-01-19 03:11:19 +03:00
|
|
|
#include "mozilla/Telemetry.h"
|
2015-04-03 16:52:00 +03:00
|
|
|
#include "mozilla/TimeStamp.h"
|
2016-08-23 07:09:32 +03:00
|
|
|
#include "mozilla/Unused.h"
|
2016-06-24 21:19:50 +03:00
|
|
|
#include "mozilla/dom/ScriptSettings.h"
|
2017-10-10 12:59:39 +03:00
|
|
|
#include "nsICrashReporter.h"
|
2015-10-06 05:00:59 +03:00
|
|
|
#include "nsThreadSyncDispatch.h"
|
2017-10-10 12:59:39 +03:00
|
|
|
#include "nsServiceManagerUtils.h"
|
2016-12-15 03:50:11 +03:00
|
|
|
#include "GeckoProfiler.h"
|
2017-03-21 10:44:12 +03:00
|
|
|
#include "InputEventStatistics.h"
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
#include "ThreadEventTarget.h"
|
2014-03-03 09:12:27 +04:00
|
|
|
|
2016-06-21 21:45:25 +03:00
|
|
|
#include "mozilla/dom/ContentChild.h"
|
2018-03-06 12:19:19 +03:00
|
|
|
#include "mozilla/dom/DOMPrefs.h"
|
2014-08-30 09:21:22 +04:00
|
|
|
|
2014-03-03 09:12:27 +04:00
|
|
|
#ifdef XP_LINUX
|
|
|
|
#include <sys/time.h>
|
|
|
|
#include <sys/resource.h>
|
|
|
|
#include <sched.h>
|
|
|
|
#endif
|
1999-04-02 13:20:44 +04:00
|
|
|
|
2010-10-27 19:16:03 +04:00
|
|
|
#define HAVE_UALARM _BSD_SOURCE || (_XOPEN_SOURCE >= 500 || \
|
|
|
|
_XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) && \
|
|
|
|
!(_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700)
|
|
|
|
|
2014-03-03 09:12:27 +04:00
|
|
|
#if defined(XP_LINUX) && !defined(ANDROID) && defined(_GNU_SOURCE)
|
|
|
|
#define HAVE_SCHED_SETAFFINITY
|
|
|
|
#endif
|
|
|
|
|
2015-12-01 06:16:40 +03:00
|
|
|
#ifdef XP_MACOSX
|
|
|
|
#include <mach/mach.h>
|
|
|
|
#include <mach/thread_policy.h>
|
|
|
|
#endif
|
|
|
|
|
2013-10-30 00:58:09 +04:00
|
|
|
#ifdef MOZ_CANARY
|
2010-10-27 19:16:03 +04:00
|
|
|
# include <unistd.h>
|
|
|
|
# include <execinfo.h>
|
|
|
|
# include <signal.h>
|
|
|
|
# include <fcntl.h>
|
|
|
|
# include "nsXULAppAPI.h"
|
|
|
|
#endif
|
|
|
|
|
2010-05-20 03:22:19 +04:00
|
|
|
#if defined(NS_FUNCTION_TIMER) && defined(_MSC_VER)
|
|
|
|
#include "nsTimerImpl.h"
|
2015-06-10 23:32:45 +03:00
|
|
|
#include "mozilla/StackWalk.h"
|
2010-05-20 03:22:19 +04:00
|
|
|
#endif
|
|
|
|
#ifdef NS_FUNCTION_TIMER
|
|
|
|
#include "nsCRT.h"
|
|
|
|
#endif
|
|
|
|
|
2014-03-27 12:49:06 +04:00
|
|
|
#ifdef MOZ_TASK_TRACER
|
|
|
|
#include "GeckoTaskTracer.h"
|
2015-06-16 05:57:19 +03:00
|
|
|
#include "TracedTaskCommon.h"
|
2014-03-27 12:49:06 +04:00
|
|
|
using namespace mozilla::tasktracer;
|
|
|
|
#endif
|
|
|
|
|
Rollup of bug 645263 and bug 646259: Switch to mozilla:: sync primitives. r=cjones,dbaron,doublec,ehsan src=bsmedberg
Bug 645263, part 0: Count sync primitive ctor/dtors. r=dbaron
Bug 645263, part 1: Migrate content/media to mozilla:: sync primitives. r=doublec
Bug 645263, part 2: Migrate modules/plugin to mozilla:: sync primitives. sr=bsmedberg
Bug 645263, part 3: Migrate nsComponentManagerImpl to mozilla:: sync primitives. sr=bsmedberg
Bug 645263, part 4: Migrate everything else to mozilla:: sync primitives. r=dbaron
Bug 645263, part 5: Remove nsAutoLock.*. sr=bsmedberg
Bug 645263, part 6: Make editor test be nicer to deadlock detector. r=ehsan
Bug 645263, part 7: Disable tracemalloc backtraces for xpcshell tests. r=dbaron
Bug 646259: Fix nsCacheService to use a CondVar for notifying. r=cjones
2011-04-01 08:29:02 +04:00
|
|
|
using namespace mozilla;
|
|
|
|
|
2015-10-19 22:50:14 +03:00
|
|
|
static LazyLogModule sThreadLog("nsThread");
|
2013-11-19 06:34:00 +04:00
|
|
|
#ifdef LOG
|
|
|
|
#undef LOG
|
|
|
|
#endif
|
2015-10-19 22:50:14 +03:00
|
|
|
#define LOG(args) MOZ_LOG(sThreadLog, mozilla::LogLevel::Debug, args)
|
1999-04-02 13:20:44 +04:00
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_DECL_CI_INTERFACE_GETTER(nsThread)
|
1999-04-02 13:20:44 +04:00
|
|
|
|
2017-07-17 18:16:44 +03:00
|
|
|
Array<char, nsThread::kRunnableNameBufSize> nsThread::sMainThreadRunnableName;
|
2017-06-30 03:09:41 +03:00
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
// Because we do not have our own nsIFactory, we have to implement nsIClassInfo
|
|
|
|
// somewhat manually.
|
2000-11-30 08:24:53 +03:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
class nsThreadClassInfo : public nsIClassInfo
|
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
public:
|
|
|
|
NS_DECL_ISUPPORTS_INHERITED // no mRefCnt
|
|
|
|
NS_DECL_NSICLASSINFO
|
2002-08-25 09:55:50 +04:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadClassInfo()
|
|
|
|
{
|
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
};
|
1999-04-02 13:20:44 +04:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
NS_IMETHODIMP_(MozExternalRefCountType)
|
|
|
|
nsThreadClassInfo::AddRef()
|
|
|
|
{
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
NS_IMETHODIMP_(MozExternalRefCountType)
|
|
|
|
nsThreadClassInfo::Release()
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
2014-04-27 11:06:00 +04:00
|
|
|
NS_IMPL_QUERY_INTERFACE(nsThreadClassInfo, nsIClassInfo)
|
1999-04-06 01:02:24 +04:00
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadClassInfo::GetInterfaces(uint32_t* aCount, nsIID*** aArray)
|
1999-04-06 01:02:24 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
return NS_CI_INTERFACE_GETTER_NAME(nsThread)(aCount, aArray);
|
1999-04-02 13:20:44 +04:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2015-03-29 17:52:54 +03:00
|
|
|
nsThreadClassInfo::GetScriptableHelper(nsIXPCScriptable** aResult)
|
1999-10-02 03:30:06 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
*aResult = nullptr;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-10-02 03:30:06 +04:00
|
|
|
}
|
|
|
|
|
1999-04-02 13:20:44 +04:00
|
|
|
NS_IMETHODIMP
|
2017-10-18 05:17:26 +03:00
|
|
|
nsThreadClassInfo::GetContractID(nsACString& aResult)
|
1999-04-02 13:20:44 +04:00
|
|
|
{
|
2017-10-18 05:17:26 +03:00
|
|
|
aResult.SetIsVoid(true);
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-04-02 13:20:44 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2017-10-18 05:17:26 +03:00
|
|
|
nsThreadClassInfo::GetClassDescription(nsACString& aResult)
|
1999-04-02 13:20:44 +04:00
|
|
|
{
|
2017-10-18 05:17:26 +03:00
|
|
|
aResult.SetIsVoid(true);
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-04-02 13:20:44 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadClassInfo::GetClassID(nsCID** aResult)
|
1999-04-02 13:20:44 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
*aResult = nullptr;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-04-02 13:20:44 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadClassInfo::GetFlags(uint32_t* aResult)
|
1999-04-02 13:20:44 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
*aResult = THREADSAFE;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-04-02 13:20:44 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadClassInfo::GetClassIDNoAlloc(nsCID* aResult)
|
1999-04-02 13:20:44 +04:00
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_ERROR_NOT_AVAILABLE;
|
|
|
|
}
|
|
|
|
|
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
|
2013-07-19 06:31:26 +04:00
|
|
|
NS_IMPL_ADDREF(nsThread)
|
|
|
|
NS_IMPL_RELEASE(nsThread)
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_INTERFACE_MAP_BEGIN(nsThread)
|
|
|
|
NS_INTERFACE_MAP_ENTRY(nsIThread)
|
|
|
|
NS_INTERFACE_MAP_ENTRY(nsIThreadInternal)
|
|
|
|
NS_INTERFACE_MAP_ENTRY(nsIEventTarget)
|
2017-05-23 00:25:43 +03:00
|
|
|
NS_INTERFACE_MAP_ENTRY(nsISerialEventTarget)
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_INTERFACE_MAP_ENTRY(nsISupportsPriority)
|
|
|
|
NS_INTERFACE_MAP_ENTRY_AMBIGUOUS(nsISupports, nsIThread)
|
|
|
|
if (aIID.Equals(NS_GET_IID(nsIClassInfo))) {
|
2013-05-31 01:20:02 +04:00
|
|
|
static nsThreadClassInfo sThreadClassInfo;
|
2007-07-08 11:08:04 +04:00
|
|
|
foundInterface = static_cast<nsIClassInfo*>(&sThreadClassInfo);
|
2006-05-10 21:30:15 +04:00
|
|
|
} else
|
|
|
|
NS_INTERFACE_MAP_END
|
2014-04-27 11:06:00 +04:00
|
|
|
NS_IMPL_CI_INTERFACE_GETTER(nsThread, nsIThread, nsIThreadInternal,
|
|
|
|
nsIEventTarget, nsISupportsPriority)
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
|
2016-04-26 03:23:21 +03:00
|
|
|
class nsThreadStartupEvent : public Runnable
|
2014-05-27 11:15:35 +04:00
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
public:
|
2013-11-20 01:27:37 +04:00
|
|
|
nsThreadStartupEvent()
|
2017-01-18 03:50:34 +03:00
|
|
|
: Runnable("nsThreadStartupEvent")
|
|
|
|
, mMon("nsThreadStartupEvent.mMon")
|
2014-05-27 11:15:35 +04:00
|
|
|
, mInitialized(false)
|
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
// This method does not return until the thread startup object is in the
|
|
|
|
// completion state.
|
2014-05-27 11:15:35 +04:00
|
|
|
void Wait()
|
|
|
|
{
|
2011-04-29 23:21:57 +04:00
|
|
|
ReentrantMonitorAutoEnter mon(mMon);
|
2014-05-27 11:15:35 +04:00
|
|
|
while (!mInitialized) {
|
2006-05-10 21:30:15 +04:00
|
|
|
mon.Wait();
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
2006-05-10 22:13:20 +04:00
|
|
|
// This method needs to be public to support older compilers (xlC_r on AIX).
|
|
|
|
// It should be called directly as this class type is reference counted.
|
2014-08-25 23:17:15 +04:00
|
|
|
virtual ~nsThreadStartupEvent() {}
|
2006-05-10 22:13:20 +04:00
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
private:
|
2016-08-08 05:18:10 +03:00
|
|
|
NS_IMETHOD Run() override
|
2014-05-27 11:15:35 +04:00
|
|
|
{
|
2011-04-29 23:21:57 +04:00
|
|
|
ReentrantMonitorAutoEnter mon(mMon);
|
2011-10-17 18:59:28 +04:00
|
|
|
mInitialized = true;
|
2006-05-10 21:30:15 +04:00
|
|
|
mon.Notify();
|
1999-04-02 13:20:44 +04:00
|
|
|
return NS_OK;
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
2011-04-29 23:21:57 +04:00
|
|
|
ReentrantMonitor mMon;
|
2014-05-27 11:15:35 +04:00
|
|
|
bool mInitialized;
|
2006-05-10 21:30:15 +04:00
|
|
|
};
|
2016-05-13 01:15:43 +03:00
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
struct nsThreadShutdownContext
|
|
|
|
{
|
2016-05-27 02:49:23 +03:00
|
|
|
nsThreadShutdownContext(NotNull<nsThread*> aTerminatingThread,
|
|
|
|
NotNull<nsThread*> aJoiningThread,
|
2016-04-20 04:49:48 +03:00
|
|
|
bool aAwaitingShutdownAck)
|
|
|
|
: mTerminatingThread(aTerminatingThread)
|
|
|
|
, mJoiningThread(aJoiningThread)
|
|
|
|
, mAwaitingShutdownAck(aAwaitingShutdownAck)
|
2017-08-21 12:30:22 +03:00
|
|
|
, mIsMainThreadJoining(NS_IsMainThread())
|
2016-02-03 21:59:26 +03:00
|
|
|
{
|
|
|
|
MOZ_COUNT_CTOR(nsThreadShutdownContext);
|
|
|
|
}
|
|
|
|
~nsThreadShutdownContext()
|
|
|
|
{
|
|
|
|
MOZ_COUNT_DTOR(nsThreadShutdownContext);
|
|
|
|
}
|
|
|
|
|
2015-09-15 04:24:43 +03:00
|
|
|
// NB: This will be the last reference.
|
2016-05-27 02:49:23 +03:00
|
|
|
NotNull<RefPtr<nsThread>> mTerminatingThread;
|
2017-04-17 21:20:21 +03:00
|
|
|
NotNull<nsThread*> MOZ_UNSAFE_REF("Thread manager is holding reference to joining thread")
|
|
|
|
mJoiningThread;
|
2016-05-27 02:49:23 +03:00
|
|
|
bool mAwaitingShutdownAck;
|
2017-08-21 12:30:22 +03:00
|
|
|
bool mIsMainThreadJoining;
|
2006-05-10 21:30:15 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
// This event is responsible for notifying nsThread::Shutdown that it is time
|
2015-09-15 04:24:43 +03:00
|
|
|
// to call PR_JoinThread. It implements nsICancelableRunnable so that it can
|
|
|
|
// run on a DOM Worker thread (where all events must implement
|
|
|
|
// nsICancelableRunnable.)
|
2016-04-26 03:23:21 +03:00
|
|
|
class nsThreadShutdownAckEvent : public CancelableRunnable
|
2014-05-27 11:15:35 +04:00
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
public:
|
2016-05-27 02:49:23 +03:00
|
|
|
explicit nsThreadShutdownAckEvent(NotNull<nsThreadShutdownContext*> aCtx)
|
2017-01-18 03:50:34 +03:00
|
|
|
: CancelableRunnable("nsThreadShutdownAckEvent")
|
|
|
|
, mShutdownContext(aCtx)
|
2014-05-27 11:15:35 +04:00
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
2015-09-15 04:24:43 +03:00
|
|
|
NS_IMETHOD Run() override
|
2014-05-27 11:15:35 +04:00
|
|
|
{
|
2016-04-20 04:46:35 +03:00
|
|
|
mShutdownContext->mTerminatingThread->ShutdownComplete(mShutdownContext);
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
2016-04-11 21:40:06 +03:00
|
|
|
nsresult Cancel() override
|
2015-09-15 04:24:43 +03:00
|
|
|
{
|
|
|
|
return Run();
|
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
private:
|
2015-09-15 04:24:43 +03:00
|
|
|
virtual ~nsThreadShutdownAckEvent() { }
|
|
|
|
|
2016-05-27 02:49:23 +03:00
|
|
|
NotNull<nsThreadShutdownContext*> mShutdownContext;
|
2006-05-10 21:30:15 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
// This event is responsible for setting mShutdownContext
|
2016-04-26 03:23:21 +03:00
|
|
|
class nsThreadShutdownEvent : public Runnable
|
2014-05-27 11:15:35 +04:00
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
public:
|
2016-05-27 02:49:23 +03:00
|
|
|
nsThreadShutdownEvent(NotNull<nsThread*> aThr,
|
|
|
|
NotNull<nsThreadShutdownContext*> aCtx)
|
2017-01-18 03:50:34 +03:00
|
|
|
: Runnable("nsThreadShutdownEvent")
|
|
|
|
, mThread(aThr)
|
2014-05-27 11:15:35 +04:00
|
|
|
, mShutdownContext(aCtx)
|
|
|
|
{
|
|
|
|
}
|
2016-08-08 05:18:10 +03:00
|
|
|
NS_IMETHOD Run() override
|
2014-05-27 11:15:35 +04:00
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
mThread->mShutdownContext = mShutdownContext;
|
2013-10-23 16:01:24 +04:00
|
|
|
MessageLoop::current()->Quit();
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
private:
|
2016-05-27 02:49:23 +03:00
|
|
|
NotNull<RefPtr<nsThread>> mThread;
|
|
|
|
NotNull<nsThreadShutdownContext*> mShutdownContext;
|
2006-05-10 21:30:15 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
|
2015-12-01 06:16:40 +03:00
|
|
|
static void
|
|
|
|
SetThreadAffinity(unsigned int cpu)
|
|
|
|
{
|
|
|
|
#ifdef HAVE_SCHED_SETAFFINITY
|
|
|
|
cpu_set_t cpus;
|
|
|
|
CPU_ZERO(&cpus);
|
|
|
|
CPU_SET(cpu, &cpus);
|
|
|
|
sched_setaffinity(0, sizeof(cpus), &cpus);
|
|
|
|
// Don't assert sched_setaffinity's return value because it intermittently (?)
|
|
|
|
// fails with EINVAL on Linux x64 try runs.
|
|
|
|
#elif defined(XP_MACOSX)
|
|
|
|
// OS X does not provide APIs to pin threads to specific processors, but you
|
|
|
|
// can tag threads as belonging to the same "affinity set" and the OS will try
|
|
|
|
// to run them on the same processor. To run threads on different processors,
|
|
|
|
// tag them as belonging to different affinity sets. Tag 0, the default, means
|
|
|
|
// "no affinity" so let's pretend each CPU has its own tag `cpu+1`.
|
|
|
|
thread_affinity_policy_data_t policy;
|
|
|
|
policy.affinity_tag = cpu + 1;
|
|
|
|
MOZ_ALWAYS_TRUE(thread_policy_set(mach_thread_self(), THREAD_AFFINITY_POLICY,
|
|
|
|
&policy.affinity_tag, 1) == KERN_SUCCESS);
|
|
|
|
#elif defined(XP_WIN)
|
2017-08-22 14:35:12 +03:00
|
|
|
MOZ_ALWAYS_TRUE(SetThreadIdealProcessor(GetCurrentThread(), cpu) != (DWORD)-1);
|
2015-12-01 06:16:40 +03:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2014-03-03 09:12:27 +04:00
|
|
|
static void
|
|
|
|
SetupCurrentThreadForChaosMode()
|
|
|
|
{
|
2015-07-15 00:29:23 +03:00
|
|
|
if (!ChaosMode::isActive(ChaosFeature::ThreadScheduling)) {
|
2014-03-03 09:12:27 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef XP_LINUX
|
|
|
|
// PR_SetThreadPriority doesn't really work since priorities >
|
|
|
|
// PR_PRIORITY_NORMAL can't be set by non-root users. Instead we'll just use
|
|
|
|
// setpriority(2) to set random 'nice values'. In regular Linux this is only
|
|
|
|
// a dynamic adjustment so it still doesn't really do what we want, but tools
|
|
|
|
// like 'rr' can be more aggressive about honoring these values.
|
|
|
|
// Some of these calls may fail due to trying to lower the priority
|
|
|
|
// (e.g. something may have already called setpriority() for this thread).
|
|
|
|
// This makes it hard to have non-main threads with higher priority than the
|
|
|
|
// main thread, but that's hard to fix. Tools like rr can choose to honor the
|
|
|
|
// requested values anyway.
|
|
|
|
// Use just 4 priorities so there's a reasonable chance of any two threads
|
|
|
|
// having equal priority.
|
|
|
|
setpriority(PRIO_PROCESS, 0, ChaosMode::randomUint32LessThan(4));
|
|
|
|
#else
|
|
|
|
// We should set the affinity here but NSPR doesn't provide a way to expose it.
|
2014-05-27 11:15:35 +04:00
|
|
|
uint32_t priority = ChaosMode::randomUint32LessThan(PR_PRIORITY_LAST + 1);
|
|
|
|
PR_SetThreadPriority(PR_GetCurrentThread(), PRThreadPriority(priority));
|
2014-03-03 09:12:27 +04:00
|
|
|
#endif
|
|
|
|
|
|
|
|
// Force half the threads to CPU 0 so they compete for CPU
|
|
|
|
if (ChaosMode::randomUint32LessThan(2)) {
|
2015-12-01 06:16:40 +03:00
|
|
|
SetThreadAffinity(0);
|
2014-03-03 09:12:27 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-20 17:10:20 +03:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
struct ThreadInitData {
|
|
|
|
nsThread* thread;
|
|
|
|
const nsACString& name;
|
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
/*static*/ void
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::ThreadFunc(void* aArg)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2014-11-21 01:16:36 +03:00
|
|
|
using mozilla::ipc::BackgroundChild;
|
|
|
|
|
2016-12-20 17:10:20 +03:00
|
|
|
ThreadInitData* initData = static_cast<ThreadInitData*>(aArg);
|
|
|
|
nsThread* self = initData->thread; // strong reference
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
self->mThread = PR_GetCurrentThread();
|
2017-05-22 21:26:39 +03:00
|
|
|
self->mVirtualThread = GetCurrentVirtualThread();
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
self->mEventTarget->SetCurrentThread();
|
2014-03-03 09:12:27 +04:00
|
|
|
SetupCurrentThreadForChaosMode();
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2017-03-14 01:03:24 +03:00
|
|
|
if (!initData->name.IsEmpty()) {
|
2017-02-07 13:57:23 +03:00
|
|
|
NS_SetCurrentThreadName(initData->name.BeginReading());
|
2016-12-20 17:10:20 +03:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
// Inform the ThreadManager
|
2016-06-10 09:04:49 +03:00
|
|
|
nsThreadManager::get().RegisterCurrentThread(*self);
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2014-04-09 08:57:52 +04:00
|
|
|
mozilla::IOInterposer::RegisterCurrentThread();
|
|
|
|
|
2017-03-14 01:03:24 +03:00
|
|
|
// This must come after the call to nsThreadManager::RegisterCurrentThread(),
|
|
|
|
// because that call is needed to properly set up this thread as an nsThread,
|
|
|
|
// which profiler_register_thread() requires. See bug 1347007.
|
|
|
|
if (!initData->name.IsEmpty()) {
|
2017-10-04 01:11:18 +03:00
|
|
|
PROFILER_REGISTER_THREAD(initData->name.BeginReading());
|
2017-03-14 01:03:24 +03:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
// Wait for and process startup event
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
nsCOMPtr<nsIRunnable> event = self->mEvents->GetEvent(true, nullptr);
|
|
|
|
MOZ_ASSERT(event);
|
2016-12-20 17:10:20 +03:00
|
|
|
|
|
|
|
initData = nullptr; // clear before unblocking nsThread::Init
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
event->Run(); // unblocks nsThread::Init
|
2012-07-30 18:20:58 +04:00
|
|
|
event = nullptr;
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
{
|
|
|
|
// Scope for MessageLoop.
|
2013-10-23 16:01:24 +04:00
|
|
|
nsAutoPtr<MessageLoop> loop(
|
2016-03-30 22:20:20 +03:00
|
|
|
new MessageLoop(MessageLoop::TYPE_MOZILLA_NONMAINTHREAD, self));
|
2013-10-23 16:01:24 +04:00
|
|
|
|
|
|
|
// Now, process incoming events...
|
|
|
|
loop->Run();
|
|
|
|
|
2014-11-21 01:16:36 +03:00
|
|
|
BackgroundChild::CloseForCurrentThread();
|
|
|
|
|
2016-01-18 20:34:38 +03:00
|
|
|
// NB: The main thread does not shut down here! It shuts down via
|
|
|
|
// nsThreadManager::Shutdown.
|
|
|
|
|
2013-10-23 16:01:24 +04:00
|
|
|
// Do NS_ProcessPendingEvents but with special handling to set
|
|
|
|
// mEventsAreDoomed atomically with the removal of the last event. The key
|
|
|
|
// invariant here is that we will never permit PutEvent to succeed if the
|
|
|
|
// event would be left in the queue after our final call to
|
2015-09-15 04:24:43 +03:00
|
|
|
// NS_ProcessPendingEvents. We also have to keep processing events as long
|
|
|
|
// as we have outstanding mRequestedShutdownContexts.
|
2013-10-23 16:01:24 +04:00
|
|
|
while (true) {
|
2015-09-15 04:24:43 +03:00
|
|
|
// Check and see if we're waiting on any threads.
|
2016-01-18 20:34:38 +03:00
|
|
|
self->WaitForAllAsynchronousShutdowns();
|
2015-09-15 04:24:43 +03:00
|
|
|
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
if (self->mEvents->ShutdownIfNoPendingEvents()) {
|
|
|
|
break;
|
2007-12-05 05:17:15 +03:00
|
|
|
}
|
2013-10-23 16:01:24 +04:00
|
|
|
NS_ProcessPendingEvents(self);
|
2007-12-05 05:17:15 +03:00
|
|
|
}
|
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2014-04-09 08:57:52 +04:00
|
|
|
mozilla::IOInterposer::UnregisterCurrentThread();
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
// Inform the threadmanager that this thread is going away
|
2016-06-10 09:04:49 +03:00
|
|
|
nsThreadManager::get().UnregisterCurrentThread(*self);
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2017-10-04 01:11:18 +03:00
|
|
|
PROFILER_UNREGISTER_THREAD();
|
2016-12-15 03:50:11 +03:00
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
// Dispatch shutdown ACK
|
2016-05-27 02:49:23 +03:00
|
|
|
NotNull<nsThreadShutdownContext*> context =
|
|
|
|
WrapNotNull(self->mShutdownContext);
|
|
|
|
MOZ_ASSERT(context->mTerminatingThread == self);
|
|
|
|
event = do_QueryObject(new nsThreadShutdownAckEvent(context));
|
2017-08-21 12:30:22 +03:00
|
|
|
if (context->mIsMainThreadJoining) {
|
|
|
|
SystemGroup::Dispatch(TaskCategory::Other, event.forget());
|
|
|
|
} else {
|
|
|
|
context->mJoiningThread->Dispatch(event, NS_DISPATCH_NORMAL);
|
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2009-06-22 17:08:04 +04:00
|
|
|
// Release any observer of the thread here.
|
2012-07-30 18:20:58 +04:00
|
|
|
self->SetObserver(nullptr);
|
2009-06-22 17:08:04 +04:00
|
|
|
|
2014-03-27 12:49:06 +04:00
|
|
|
#ifdef MOZ_TASK_TRACER
|
|
|
|
FreeTraceInfo();
|
|
|
|
#endif
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_RELEASE(self);
|
1999-04-02 13:20:44 +04:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
|
2014-08-30 09:21:22 +04:00
|
|
|
// Tell the crash reporter to save a memory report if our heuristics determine
|
|
|
|
// that an OOM failure is likely to occur soon.
|
2016-06-21 21:45:25 +03:00
|
|
|
// Memory usage will not be checked more than every 30 seconds or saved more
|
|
|
|
// than every 3 minutes
|
|
|
|
// If |aShouldSave == kForceReport|, a report will be saved regardless of
|
|
|
|
// whether the process is low on memory or not. However, it will still not be
|
|
|
|
// saved if a report was saved less than 3 minutes ago.
|
|
|
|
bool
|
|
|
|
nsThread::SaveMemoryReportNearOOM(ShouldSaveMemoryReport aShouldSave)
|
2014-08-30 09:21:22 +04:00
|
|
|
{
|
2016-06-21 21:45:25 +03:00
|
|
|
// Keep an eye on memory usage (cheap, ~7ms) somewhat frequently,
|
|
|
|
// but save memory reports (expensive, ~75ms) less frequently.
|
|
|
|
const size_t kLowMemoryCheckSeconds = 30;
|
|
|
|
const size_t kLowMemorySaveSeconds = 3 * 60;
|
2014-08-30 09:21:22 +04:00
|
|
|
|
2016-06-21 21:45:25 +03:00
|
|
|
static TimeStamp nextCheck = TimeStamp::NowLoRes()
|
|
|
|
+ TimeDuration::FromSeconds(kLowMemoryCheckSeconds);
|
|
|
|
static bool recentlySavedReport = false; // Keeps track of whether a report
|
|
|
|
// was saved last time we checked
|
|
|
|
|
|
|
|
// Are we checking again too soon?
|
|
|
|
TimeStamp now = TimeStamp::NowLoRes();
|
|
|
|
if ((aShouldSave == ShouldSaveMemoryReport::kMaybeReport ||
|
|
|
|
recentlySavedReport) && now < nextCheck) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool needMemoryReport = (aShouldSave == ShouldSaveMemoryReport::kForceReport);
|
2014-08-30 09:21:22 +04:00
|
|
|
#ifdef XP_WIN // XXX implement on other platforms as needed
|
2016-06-21 21:45:25 +03:00
|
|
|
// If the report is forced there is no need to check whether it is necessary
|
|
|
|
if (aShouldSave != ShouldSaveMemoryReport::kForceReport) {
|
|
|
|
const size_t LOWMEM_THRESHOLD_VIRTUAL = 200 * 1024 * 1024;
|
|
|
|
MEMORYSTATUSEX statex;
|
|
|
|
statex.dwLength = sizeof(statex);
|
|
|
|
if (GlobalMemoryStatusEx(&statex)) {
|
|
|
|
if (statex.ullAvailVirtual < LOWMEM_THRESHOLD_VIRTUAL) {
|
|
|
|
needMemoryReport = true;
|
|
|
|
}
|
2014-08-30 09:21:22 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (needMemoryReport) {
|
2016-06-21 21:45:25 +03:00
|
|
|
if (XRE_IsContentProcess()) {
|
|
|
|
dom::ContentChild* cc = dom::ContentChild::GetSingleton();
|
|
|
|
if (cc) {
|
|
|
|
cc->SendNotifyLowMemory();
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
nsCOMPtr<nsICrashReporter> cr =
|
|
|
|
do_GetService("@mozilla.org/toolkit/crash-reporter;1");
|
|
|
|
if (cr) {
|
|
|
|
cr->SaveMemoryReport();
|
|
|
|
}
|
2016-05-03 10:08:04 +03:00
|
|
|
}
|
2016-06-21 21:45:25 +03:00
|
|
|
recentlySavedReport = true;
|
|
|
|
nextCheck = now + TimeDuration::FromSeconds(kLowMemorySaveSeconds);
|
|
|
|
} else {
|
|
|
|
recentlySavedReport = false;
|
|
|
|
nextCheck = now + TimeDuration::FromSeconds(kLowMemoryCheckSeconds);
|
2014-08-30 09:21:22 +04:00
|
|
|
}
|
|
|
|
|
2016-06-21 21:45:25 +03:00
|
|
|
return recentlySavedReport;
|
2014-08-30 09:21:22 +04:00
|
|
|
}
|
|
|
|
|
2013-10-30 00:58:09 +04:00
|
|
|
#ifdef MOZ_CANARY
|
|
|
|
int sCanaryOutputFD = -1;
|
|
|
|
#endif
|
|
|
|
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
nsThread::nsThread(NotNull<SynchronizedEventQueue*> aQueue,
|
|
|
|
MainThreadFlag aMainThread,
|
|
|
|
uint32_t aStackSize)
|
|
|
|
: mEvents(aQueue.get())
|
|
|
|
, mEventTarget(new ThreadEventTarget(mEvents.get(), aMainThread == MAIN_THREAD))
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
, mScriptObserver(nullptr)
|
2011-07-27 07:26:47 +04:00
|
|
|
, mPriority(PRIORITY_NORMAL)
|
2012-07-30 18:20:58 +04:00
|
|
|
, mThread(nullptr)
|
2015-04-24 23:04:50 +03:00
|
|
|
, mNestedEventLoopDepth(0)
|
2011-07-27 07:26:47 +04:00
|
|
|
, mStackSize(aStackSize)
|
2012-07-30 18:20:58 +04:00
|
|
|
, mShutdownContext(nullptr)
|
2011-10-17 18:59:28 +04:00
|
|
|
, mShutdownRequired(false)
|
2011-10-12 21:52:26 +04:00
|
|
|
, mIsMainThread(aMainThread)
|
2017-05-10 02:16:51 +03:00
|
|
|
, mLastUnlabeledRunnable(TimeStamp::Now())
|
2016-09-16 07:35:14 +03:00
|
|
|
, mCanInvokeJS(false)
|
2018-03-06 12:19:19 +03:00
|
|
|
, mCurrentEvent(nullptr)
|
|
|
|
, mCurrentEventStart(TimeStamp::Now())
|
|
|
|
, mCurrentEventLoopDepth(-1)
|
|
|
|
, mCurrentPerformanceCounter(nullptr)
|
1999-04-06 01:02:24 +04:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
nsThread::~nsThread()
|
|
|
|
{
|
2016-02-03 21:59:26 +03:00
|
|
|
NS_ASSERTION(mRequestedShutdownContexts.IsEmpty(),
|
|
|
|
"shouldn't be waiting on other threads to shutdown");
|
|
|
|
#ifdef DEBUG
|
|
|
|
// We deliberately leak these so they can be tracked by the leak checker.
|
|
|
|
// If you're having nsThreadShutdownContext leaks, you can set:
|
|
|
|
// XPCOM_MEM_LOG_CLASSES=nsThreadShutdownContext
|
|
|
|
// during a test run and that will at least tell you what thread is
|
|
|
|
// requesting shutdown on another, which can be helpful for diagnosing
|
|
|
|
// the leak.
|
|
|
|
for (size_t i = 0; i < mRequestedShutdownContexts.Length(); ++i) {
|
|
|
|
Unused << mRequestedShutdownContexts[i].forget();
|
|
|
|
}
|
|
|
|
#endif
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
2018-03-06 12:19:19 +03:00
|
|
|
bool
|
|
|
|
nsThread::GetSchedulerLoggingEnabled() {
|
|
|
|
if (!NS_IsMainThread() || !mozilla::Preferences::IsServiceAvailable()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return mozilla::dom::DOMPrefs::SchedulerLoggingEnabled();
|
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
nsresult
|
2016-12-20 17:10:20 +03:00
|
|
|
nsThread::Init(const nsACString& aName)
|
1999-10-02 03:30:06 +04:00
|
|
|
{
|
2006-05-10 21:30:15 +04:00
|
|
|
// spawn thread and wait until it is fully setup
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<nsThreadStartupEvent> startup = new nsThreadStartupEvent();
|
2014-05-27 11:15:35 +04:00
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_ADDREF_THIS();
|
2014-05-27 11:15:35 +04:00
|
|
|
|
2011-10-17 18:59:28 +04:00
|
|
|
mShutdownRequired = true;
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2016-12-20 17:10:20 +03:00
|
|
|
ThreadInitData initData = { this, aName };
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
// ThreadFunc is responsible for setting mThread
|
2016-12-20 17:10:20 +03:00
|
|
|
if (!PR_CreateThread(PR_USER_THREAD, ThreadFunc, &initData,
|
2016-05-27 02:49:23 +03:00
|
|
|
PR_PRIORITY_NORMAL, PR_GLOBAL_THREAD,
|
|
|
|
PR_JOINABLE_THREAD, mStackSize)) {
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_RELEASE_THIS();
|
|
|
|
return NS_ERROR_OUT_OF_MEMORY;
|
|
|
|
}
|
|
|
|
|
|
|
|
// ThreadFunc will wait for this event to be run before it tries to access
|
|
|
|
// mThread. By delaying insertion of this event into the queue, we ensure
|
|
|
|
// that mThread is set properly.
|
|
|
|
{
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
mEvents->PutEvent(do_AddRef(startup), EventPriority::Normal); // retain a reference
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
// Wait for thread to call ThreadManager::SetupCurrentThread, which completes
|
|
|
|
// initialization of ThreadFunc.
|
|
|
|
startup->Wait();
|
|
|
|
return NS_OK;
|
|
|
|
}
|
2002-06-11 23:26:04 +04:00
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
nsresult
|
|
|
|
nsThread::InitCurrentThread()
|
|
|
|
{
|
|
|
|
mThread = PR_GetCurrentThread();
|
2017-05-22 21:26:39 +03:00
|
|
|
mVirtualThread = GetCurrentVirtualThread();
|
2014-03-03 09:12:27 +04:00
|
|
|
SetupCurrentThreadForChaosMode();
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2016-06-10 09:04:49 +03:00
|
|
|
nsThreadManager::get().RegisterCurrentThread(*this);
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-10-02 03:30:06 +04:00
|
|
|
}
|
|
|
|
|
2013-11-14 22:06:17 +04:00
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
// nsIEventTarget
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2015-07-10 06:21:46 +03:00
|
|
|
nsThread::DispatchFromScript(nsIRunnable* aEvent, uint32_t aFlags)
|
2013-11-14 22:06:17 +04:00
|
|
|
{
|
2015-07-10 06:21:46 +03:00
|
|
|
nsCOMPtr<nsIRunnable> event(aEvent);
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
return mEventTarget->Dispatch(event.forget(), aFlags);
|
2015-07-10 06:21:46 +03:00
|
|
|
}
|
2013-11-14 22:06:17 +04:00
|
|
|
|
2015-07-10 06:21:46 +03:00
|
|
|
NS_IMETHODIMP
|
2016-06-01 03:04:54 +03:00
|
|
|
nsThread::Dispatch(already_AddRefed<nsIRunnable> aEvent, uint32_t aFlags)
|
2015-07-10 06:21:46 +03:00
|
|
|
{
|
|
|
|
LOG(("THRD(%p) Dispatch [%p %x]\n", this, /* XXX aEvent */nullptr, aFlags));
|
|
|
|
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
return mEventTarget->Dispatch(Move(aEvent), aFlags);
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
2000-11-30 08:24:53 +03:00
|
|
|
|
2016-05-13 01:15:43 +03:00
|
|
|
NS_IMETHODIMP
|
2016-06-01 03:04:54 +03:00
|
|
|
nsThread::DelayedDispatch(already_AddRefed<nsIRunnable> aEvent, uint32_t aDelayMs)
|
2016-05-13 01:15:43 +03:00
|
|
|
{
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
return mEventTarget->DelayedDispatch(Move(aEvent), aDelayMs);
|
2016-05-13 01:15:43 +03:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::IsOnCurrentThread(bool* aResult)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
return mEventTarget->IsOnCurrentThread(aResult);
|
2000-11-30 08:24:53 +03:00
|
|
|
}
|
|
|
|
|
2017-05-22 21:26:39 +03:00
|
|
|
NS_IMETHODIMP_(bool)
|
|
|
|
nsThread::IsOnCurrentThreadInfallible()
|
|
|
|
{
|
|
|
|
// Rely on mVirtualThread being correct.
|
|
|
|
MOZ_CRASH("IsOnCurrentThreadInfallible should never be called on nsIThread");
|
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
// nsIThread
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::GetPRThread(PRThread** aResult)
|
1999-04-02 13:20:44 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
*aResult = mThread;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-04-02 13:20:44 +04:00
|
|
|
}
|
|
|
|
|
2016-09-16 07:35:14 +03:00
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThread::GetCanInvokeJS(bool* aResult)
|
|
|
|
{
|
|
|
|
*aResult = mCanInvokeJS;
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThread::SetCanInvokeJS(bool aCanInvokeJS)
|
|
|
|
{
|
|
|
|
mCanInvokeJS = aCanInvokeJS;
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2015-09-15 04:24:43 +03:00
|
|
|
nsThread::AsyncShutdown()
|
1999-10-02 03:30:06 +04:00
|
|
|
{
|
2015-09-15 04:24:43 +03:00
|
|
|
LOG(("THRD(%p) async shutdown\n", this));
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
// XXX If we make this warn, then we hit that warning at xpcom shutdown while
|
|
|
|
// shutting down a thread in a thread pool. That happens b/c the thread
|
|
|
|
// in the thread pool is already shutdown by the thread manager.
|
2014-05-27 11:15:35 +04:00
|
|
|
if (!mThread) {
|
1999-10-02 03:30:06 +04:00
|
|
|
return NS_OK;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2015-09-15 04:24:43 +03:00
|
|
|
return !!ShutdownInternal(/* aSync = */ false) ? NS_OK : NS_ERROR_UNEXPECTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsThreadShutdownContext*
|
|
|
|
nsThread::ShutdownInternal(bool aSync)
|
|
|
|
{
|
|
|
|
MOZ_ASSERT(mThread);
|
2016-04-27 08:49:48 +03:00
|
|
|
MOZ_ASSERT(mThread != PR_GetCurrentThread());
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(mThread == PR_GetCurrentThread())) {
|
2015-09-15 04:24:43 +03:00
|
|
|
return nullptr;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
// Prevent multiple calls to this method
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
if (!mShutdownRequired.compareExchange(true, false)) {
|
|
|
|
return nullptr;
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
2016-05-27 02:49:23 +03:00
|
|
|
NotNull<nsThread*> currentThread =
|
2016-06-10 09:04:49 +03:00
|
|
|
WrapNotNull(nsThreadManager::get().GetCurrentThread());
|
2015-09-15 04:24:43 +03:00
|
|
|
|
|
|
|
nsAutoPtr<nsThreadShutdownContext>& context =
|
|
|
|
*currentThread->mRequestedShutdownContexts.AppendElement();
|
2016-05-27 02:49:23 +03:00
|
|
|
context = new nsThreadShutdownContext(WrapNotNull(this), currentThread, aSync);
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
// Set mShutdownContext and wake up the thread in case it is waiting for
|
|
|
|
// events to process.
|
2016-05-27 02:49:23 +03:00
|
|
|
nsCOMPtr<nsIRunnable> event =
|
|
|
|
new nsThreadShutdownEvent(WrapNotNull(this), WrapNotNull(context.get()));
|
2007-12-05 05:17:15 +03:00
|
|
|
// XXXroc What if posting the event fails due to OOM?
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
mEvents->PutEvent(event.forget(), EventPriority::Normal);
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
// We could still end up with other events being added after the shutdown
|
|
|
|
// task, but that's okay because we process pending events in ThreadFunc
|
|
|
|
// after setting mShutdownContext just before exiting.
|
2015-09-15 04:24:43 +03:00
|
|
|
return context;
|
|
|
|
}
|
2014-05-27 11:15:35 +04:00
|
|
|
|
2015-09-15 04:24:43 +03:00
|
|
|
void
|
2016-05-27 02:49:23 +03:00
|
|
|
nsThread::ShutdownComplete(NotNull<nsThreadShutdownContext*> aContext)
|
2015-09-15 04:24:43 +03:00
|
|
|
{
|
|
|
|
MOZ_ASSERT(mThread);
|
2016-04-20 04:46:35 +03:00
|
|
|
MOZ_ASSERT(aContext->mTerminatingThread == this);
|
2015-09-15 04:24:43 +03:00
|
|
|
|
2016-04-20 04:46:35 +03:00
|
|
|
if (aContext->mAwaitingShutdownAck) {
|
2015-09-15 04:24:43 +03:00
|
|
|
// We're in a synchronous shutdown, so tell whatever is up the stack that
|
|
|
|
// we're done and unwind the stack so it can call us again.
|
2016-04-20 04:46:35 +03:00
|
|
|
aContext->mAwaitingShutdownAck = false;
|
2015-09-15 04:24:43 +03:00
|
|
|
return;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
// Now, it should be safe to join without fear of dead-locking.
|
|
|
|
|
|
|
|
PR_JoinThread(mThread);
|
2012-07-30 18:20:58 +04:00
|
|
|
mThread = nullptr;
|
2009-06-22 17:08:04 +04:00
|
|
|
|
2012-01-14 22:31:13 +04:00
|
|
|
// We hold strong references to our event observers, and once the thread is
|
|
|
|
// shut down the observers can't easily unregister themselves. Do it here
|
|
|
|
// to avoid leaking.
|
|
|
|
ClearObservers();
|
|
|
|
|
2009-06-22 17:08:04 +04:00
|
|
|
#ifdef DEBUG
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
nsCOMPtr<nsIThreadObserver> obs = mEvents->GetObserver();
|
|
|
|
MOZ_ASSERT(!obs, "Should have been cleared at shutdown!");
|
2009-06-22 17:08:04 +04:00
|
|
|
#endif
|
|
|
|
|
2015-09-15 04:24:43 +03:00
|
|
|
// Delete aContext.
|
|
|
|
MOZ_ALWAYS_TRUE(
|
2016-04-20 04:46:35 +03:00
|
|
|
aContext->mJoiningThread->mRequestedShutdownContexts.RemoveElement(aContext));
|
2015-09-15 04:24:43 +03:00
|
|
|
}
|
|
|
|
|
2016-01-18 20:34:38 +03:00
|
|
|
void
|
|
|
|
nsThread::WaitForAllAsynchronousShutdowns()
|
|
|
|
{
|
2017-05-15 16:34:19 +03:00
|
|
|
// This is the motivating example for why SpinEventLoop has the template
|
|
|
|
// parameter we are providing here.
|
|
|
|
SpinEventLoopUntil<ProcessFailureBehavior::IgnoreAndContinue>([&]() {
|
|
|
|
return mRequestedShutdownContexts.IsEmpty();
|
|
|
|
}, this);
|
2016-01-18 20:34:38 +03:00
|
|
|
}
|
|
|
|
|
2015-09-15 04:24:43 +03:00
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThread::Shutdown()
|
|
|
|
{
|
|
|
|
LOG(("THRD(%p) sync shutdown\n", this));
|
|
|
|
|
|
|
|
// XXX If we make this warn, then we hit that warning at xpcom shutdown while
|
|
|
|
// shutting down a thread in a thread pool. That happens b/c the thread
|
|
|
|
// in the thread pool is already shutdown by the thread manager.
|
|
|
|
if (!mThread) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2016-05-27 02:49:23 +03:00
|
|
|
nsThreadShutdownContext* maybeContext = ShutdownInternal(/* aSync = */ true);
|
|
|
|
NS_ENSURE_TRUE(maybeContext, NS_ERROR_UNEXPECTED);
|
|
|
|
NotNull<nsThreadShutdownContext*> context = WrapNotNull(maybeContext);
|
2015-09-15 04:24:43 +03:00
|
|
|
|
|
|
|
// Process events on the current thread until we receive a shutdown ACK.
|
|
|
|
// Allows waiting; ensure no locks are held that would deadlock us!
|
2017-05-15 16:34:19 +03:00
|
|
|
SpinEventLoopUntil([&, context]() {
|
|
|
|
return !context->mAwaitingShutdownAck;
|
|
|
|
}, context->mJoiningThread);
|
2015-09-15 04:24:43 +03:00
|
|
|
|
|
|
|
ShutdownComplete(context);
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-10-02 03:30:06 +04:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::HasPendingEvents(bool* aResult)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(PR_GetCurrentThread() != mThread)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_NOT_SAME_THREAD;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
1999-04-02 13:20:44 +04:00
|
|
|
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
*aResult = mEvents->HasPendingEvent();
|
2016-08-24 17:18:06 +03:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThread::IdleDispatch(already_AddRefed<nsIRunnable> aEvent)
|
|
|
|
{
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
nsCOMPtr<nsIRunnable> event = aEvent;
|
2016-08-24 17:18:06 +03:00
|
|
|
|
|
|
|
if (NS_WARN_IF(!event)) {
|
|
|
|
return NS_ERROR_INVALID_ARG;
|
|
|
|
}
|
|
|
|
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
if (!mEvents->PutEvent(event.forget(), EventPriority::Idle)) {
|
2016-08-24 17:18:06 +03:00
|
|
|
NS_WARNING("An idle event was posted to a thread that will never run it (rejected)");
|
|
|
|
return NS_ERROR_UNEXPECTED;
|
|
|
|
}
|
|
|
|
|
2017-03-21 10:44:12 +03:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2010-10-27 19:16:03 +04:00
|
|
|
#ifdef MOZ_CANARY
|
2014-05-27 11:15:35 +04:00
|
|
|
void canary_alarm_handler(int signum);
|
2010-10-27 19:16:03 +04:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
class Canary
|
|
|
|
{
|
|
|
|
//XXX ToDo: support nested loops
|
2010-10-27 19:16:03 +04:00
|
|
|
public:
|
2014-05-27 11:15:35 +04:00
|
|
|
Canary()
|
|
|
|
{
|
2013-10-30 00:58:09 +04:00
|
|
|
if (sCanaryOutputFD > 0 && EventLatencyIsImportant()) {
|
2010-10-27 19:16:03 +04:00
|
|
|
signal(SIGALRM, canary_alarm_handler);
|
2014-05-27 11:15:35 +04:00
|
|
|
ualarm(15000, 0);
|
2010-10-27 19:16:03 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
~Canary()
|
|
|
|
{
|
|
|
|
if (sCanaryOutputFD != 0 && EventLatencyIsImportant()) {
|
2010-10-27 19:16:03 +04:00
|
|
|
ualarm(0, 0);
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2010-10-27 19:16:03 +04:00
|
|
|
}
|
2011-01-06 01:11:56 +03:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
static bool EventLatencyIsImportant()
|
|
|
|
{
|
2015-07-04 04:29:00 +03:00
|
|
|
return NS_IsMainThread() && XRE_IsParentProcess();
|
2011-01-06 01:11:56 +03:00
|
|
|
}
|
2010-10-27 19:16:03 +04:00
|
|
|
};
|
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
void canary_alarm_handler(int signum)
|
2010-10-27 19:16:03 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
void* array[30];
|
2010-10-27 19:16:03 +04:00
|
|
|
const char msg[29] = "event took too long to run:\n";
|
|
|
|
// use write to be safe in the signal handler
|
2014-05-27 11:15:35 +04:00
|
|
|
write(sCanaryOutputFD, msg, sizeof(msg));
|
2013-10-30 00:58:09 +04:00
|
|
|
backtrace_symbols_fd(array, backtrace(array, 30), sCanaryOutputFD);
|
2010-10-27 19:16:03 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2017-08-21 23:26:14 +03:00
|
|
|
#define NOTIFY_EVENT_OBSERVERS(observers_, func_, params_) \
|
2017-04-06 04:06:44 +03:00
|
|
|
do { \
|
2017-08-21 23:26:14 +03:00
|
|
|
if (!observers_.IsEmpty()) { \
|
|
|
|
nsTObserverArray<nsCOMPtr<nsIThreadObserver>>::ForwardIterator \
|
|
|
|
iter_(observers_); \
|
2010-11-19 01:19:19 +03:00
|
|
|
nsCOMPtr<nsIThreadObserver> obs_; \
|
|
|
|
while (iter_.HasMore()) { \
|
|
|
|
obs_ = iter_.GetNext(); \
|
|
|
|
obs_ -> func_ params_ ; \
|
|
|
|
} \
|
|
|
|
} \
|
2017-04-06 04:06:44 +03:00
|
|
|
} while(0)
|
2010-11-19 01:19:19 +03:00
|
|
|
|
2018-03-23 21:53:55 +03:00
|
|
|
#ifdef MOZ_COLLECTING_RUNNABLE_TELEMETRY
|
2017-05-29 20:45:33 +03:00
|
|
|
static bool
|
2017-11-14 22:52:32 +03:00
|
|
|
GetLabeledRunnableName(nsIRunnable* aEvent,
|
|
|
|
nsACString& aName,
|
|
|
|
EventPriority aPriority)
|
2017-05-29 20:45:33 +03:00
|
|
|
{
|
|
|
|
bool labeled = false;
|
|
|
|
if (RefPtr<SchedulerGroup::Runnable> groupRunnable = do_QueryObject(aEvent)) {
|
|
|
|
labeled = true;
|
|
|
|
MOZ_ALWAYS_TRUE(NS_SUCCEEDED(groupRunnable->GetName(aName)));
|
|
|
|
} else if (nsCOMPtr<nsINamed> named = do_QueryInterface(aEvent)) {
|
|
|
|
MOZ_ALWAYS_TRUE(NS_SUCCEEDED(named->GetName(aName)));
|
|
|
|
} else {
|
|
|
|
aName.AssignLiteral("non-nsINamed runnable");
|
|
|
|
}
|
|
|
|
if (aName.IsEmpty()) {
|
|
|
|
aName.AssignLiteral("anonymous runnable");
|
|
|
|
}
|
|
|
|
|
2017-11-14 22:52:32 +03:00
|
|
|
if (!labeled && aPriority > EventPriority::Input) {
|
|
|
|
aName.AppendLiteral("(unlabeled)");
|
|
|
|
}
|
|
|
|
|
2017-05-29 20:45:33 +03:00
|
|
|
return labeled;
|
|
|
|
}
|
2018-04-24 23:03:06 +03:00
|
|
|
#endif
|
2018-03-06 12:19:19 +03:00
|
|
|
|
|
|
|
mozilla::PerformanceCounter*
|
|
|
|
nsThread::GetPerformanceCounter(nsIRunnable* aEvent)
|
|
|
|
{
|
|
|
|
RefPtr<SchedulerGroup::Runnable> docRunnable = do_QueryObject(aEvent);
|
|
|
|
if (docRunnable) {
|
|
|
|
mozilla::dom::DocGroup* docGroup = docRunnable->DocGroup();
|
|
|
|
if (docGroup) {
|
|
|
|
return docGroup->GetPerformanceCounter();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::ProcessNextEvent(bool aMayWait, bool* aResult)
|
1999-04-06 01:02:24 +04:00
|
|
|
{
|
2015-04-24 23:04:50 +03:00
|
|
|
LOG(("THRD(%p) ProcessNextEvent [%u %u]\n", this, aMayWait,
|
|
|
|
mNestedEventLoopDepth));
|
1999-04-06 01:02:24 +04:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(PR_GetCurrentThread() != mThread)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_NOT_SAME_THREAD;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
1999-04-06 01:02:24 +04:00
|
|
|
|
2014-02-01 05:14:00 +04:00
|
|
|
// The toplevel event loop normally blocks waiting for the next event, but
|
|
|
|
// if we're trying to shut this thread down, we must exit the event loop when
|
|
|
|
// the event queue is empty.
|
|
|
|
// This only applys to the toplevel event loop! Nested event loops (e.g.
|
|
|
|
// during sync dispatch) are waiting for some state change and must be able
|
|
|
|
// to block even if something has requested shutdown of the thread. Otherwise
|
|
|
|
// we'll just busywait as we endlessly look for an event, fail to find one,
|
|
|
|
// and repeat the nested event loop since its state change hasn't happened yet.
|
2015-04-24 23:04:50 +03:00
|
|
|
bool reallyWait = aMayWait && (mNestedEventLoopDepth > 0 || !ShuttingDown());
|
2014-02-01 04:42:24 +04:00
|
|
|
|
2017-07-29 00:56:49 +03:00
|
|
|
Maybe<Scheduler::EventLoopActivation> activation;
|
2016-05-22 15:30:03 +03:00
|
|
|
if (mIsMainThread == MAIN_THREAD) {
|
|
|
|
DoMainThreadSpecificProcessing(reallyWait);
|
2017-07-29 00:56:49 +03:00
|
|
|
activation.emplace();
|
2014-08-30 09:21:22 +04:00
|
|
|
}
|
|
|
|
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
++mNestedEventLoopDepth;
|
|
|
|
|
2016-06-24 21:19:50 +03:00
|
|
|
// We only want to create an AutoNoJSAPI on threads that actually do DOM stuff
|
|
|
|
// (including workers). Those are exactly the threads that have an
|
|
|
|
// mScriptObserver.
|
|
|
|
Maybe<dom::AutoNoJSAPI> noJSAPI;
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
bool callScriptObserver = !!mScriptObserver;
|
|
|
|
if (callScriptObserver) {
|
2016-06-24 21:19:50 +03:00
|
|
|
noJSAPI.emplace();
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
mScriptObserver->BeforeProcessTask(reallyWait);
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2012-10-24 02:26:36 +04:00
|
|
|
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
nsCOMPtr<nsIThreadObserver> obs = mEvents->GetObserverOnThread();
|
2014-05-27 11:15:35 +04:00
|
|
|
if (obs) {
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
obs->OnProcessNextEvent(this, reallyWait);
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
1999-04-06 01:02:24 +04:00
|
|
|
|
2017-08-21 23:26:14 +03:00
|
|
|
NOTIFY_EVENT_OBSERVERS(EventQueue()->EventObservers(), OnProcessNextEvent, (this, reallyWait));
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2010-10-27 19:16:03 +04:00
|
|
|
#ifdef MOZ_CANARY
|
|
|
|
Canary canary;
|
|
|
|
#endif
|
2006-05-10 21:30:15 +04:00
|
|
|
nsresult rv = NS_OK;
|
|
|
|
|
2009-06-11 21:09:35 +04:00
|
|
|
{
|
|
|
|
// Scope for |event| to make sure that its destructor fires while
|
2015-04-24 23:04:50 +03:00
|
|
|
// mNestedEventLoopDepth has been incremented, since that destructor can
|
2009-06-11 21:09:35 +04:00
|
|
|
// also do work.
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
EventPriority priority;
|
|
|
|
nsCOMPtr<nsIRunnable> event = mEvents->GetEvent(reallyWait, &priority);
|
2009-06-11 21:09:35 +04:00
|
|
|
|
2017-07-29 00:56:49 +03:00
|
|
|
if (activation.isSome()) {
|
|
|
|
activation.ref().SetEvent(event, priority);
|
|
|
|
}
|
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
*aResult = (event.get() != nullptr);
|
2009-06-11 21:09:35 +04:00
|
|
|
|
|
|
|
if (event) {
|
|
|
|
LOG(("THRD(%p) running [%p]\n", this, event.get()));
|
2017-05-29 20:45:33 +03:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
if (MAIN_THREAD == mIsMainThread) {
|
2011-10-12 21:52:26 +04:00
|
|
|
HangMonitor::NotifyActivity();
|
2017-05-29 20:45:33 +03:00
|
|
|
}
|
2017-01-19 03:11:19 +03:00
|
|
|
|
2018-03-06 12:19:19 +03:00
|
|
|
bool schedulerLoggingEnabled = GetSchedulerLoggingEnabled();
|
|
|
|
if (schedulerLoggingEnabled
|
|
|
|
&& mNestedEventLoopDepth > mCurrentEventLoopDepth
|
|
|
|
&& mCurrentPerformanceCounter) {
|
|
|
|
// This is a recursive call, we're saving the time
|
|
|
|
// spent in the parent event if the runnable is linked to a DocGroup.
|
|
|
|
mozilla::TimeDuration duration = TimeStamp::Now() - mCurrentEventStart;
|
|
|
|
mCurrentPerformanceCounter->IncrementExecutionDuration(duration.ToMicroseconds());
|
|
|
|
}
|
|
|
|
|
2018-04-24 23:03:06 +03:00
|
|
|
#ifdef MOZ_COLLECTING_RUNNABLE_TELEMETRY
|
2017-05-29 20:45:33 +03:00
|
|
|
Maybe<Telemetry::AutoTimer<Telemetry::MAIN_THREAD_RUNNABLE_MS>> timer;
|
|
|
|
Maybe<Telemetry::AutoTimer<Telemetry::IDLE_RUNNABLE_BUDGET_OVERUSE_MS>> idleTimer;
|
|
|
|
|
2017-06-30 03:09:41 +03:00
|
|
|
nsAutoCString name;
|
2017-05-29 20:45:33 +03:00
|
|
|
if ((MAIN_THREAD == mIsMainThread) || mNextIdleDeadline) {
|
2017-11-14 22:52:32 +03:00
|
|
|
bool labeled = GetLabeledRunnableName(event, name, priority);
|
2017-05-29 20:45:33 +03:00
|
|
|
|
|
|
|
if (MAIN_THREAD == mIsMainThread) {
|
|
|
|
timer.emplace(name);
|
|
|
|
|
|
|
|
// High-priority runnables are ignored here since they'll run right away
|
|
|
|
// even with the cooperative scheduler.
|
2017-12-16 00:20:23 +03:00
|
|
|
if (!labeled && (priority == EventPriority::Normal ||
|
|
|
|
priority == EventPriority::Idle)) {
|
2017-05-29 20:45:33 +03:00
|
|
|
TimeStamp now = TimeStamp::Now();
|
|
|
|
double diff = (now - mLastUnlabeledRunnable).ToMilliseconds();
|
|
|
|
Telemetry::Accumulate(Telemetry::TIME_BETWEEN_UNLABELED_RUNNABLES_MS, diff);
|
|
|
|
mLastUnlabeledRunnable = now;
|
|
|
|
}
|
2017-05-10 02:16:51 +03:00
|
|
|
}
|
|
|
|
|
2017-05-29 20:45:33 +03:00
|
|
|
if (mNextIdleDeadline) {
|
|
|
|
// If we construct the AutoTimer with the deadline, then we'll
|
|
|
|
// compute TimeStamp::Now() - mNextIdleDeadline when
|
|
|
|
// accumulating telemetry. If that is positive we've
|
|
|
|
// overdrawn our idle budget, if it's negative it will go in
|
|
|
|
// the 0 bucket of the histogram.
|
|
|
|
idleTimer.emplace(name, mNextIdleDeadline);
|
2017-05-10 02:16:51 +03:00
|
|
|
}
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2017-06-30 03:09:41 +03:00
|
|
|
|
|
|
|
// If we're on the main thread, we want to record our current runnable's
|
|
|
|
// name in a static so that BHR can record it.
|
2017-07-17 18:16:44 +03:00
|
|
|
Array<char, kRunnableNameBufSize> restoreRunnableName;
|
|
|
|
restoreRunnableName[0] = '\0';
|
2017-06-30 03:09:41 +03:00
|
|
|
auto clear = MakeScopeExit([&] {
|
|
|
|
if (MAIN_THREAD == mIsMainThread) {
|
2017-07-17 18:16:44 +03:00
|
|
|
MOZ_ASSERT(NS_IsMainThread());
|
2017-06-30 03:09:41 +03:00
|
|
|
sMainThreadRunnableName = restoreRunnableName;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
if (MAIN_THREAD == mIsMainThread) {
|
2017-07-17 18:16:44 +03:00
|
|
|
MOZ_ASSERT(NS_IsMainThread());
|
2017-06-30 03:09:41 +03:00
|
|
|
restoreRunnableName = sMainThreadRunnableName;
|
2017-07-17 18:16:44 +03:00
|
|
|
|
|
|
|
// Copy the name into sMainThreadRunnableName's buffer, and append a
|
|
|
|
// terminating null.
|
|
|
|
uint32_t length = std::min((uint32_t) kRunnableNameBufSize - 1,
|
|
|
|
(uint32_t) name.Length());
|
|
|
|
memcpy(sMainThreadRunnableName.begin(), name.BeginReading(), length);
|
|
|
|
sMainThreadRunnableName[length] = '\0';
|
2017-06-30 03:09:41 +03:00
|
|
|
}
|
2017-05-29 20:45:33 +03:00
|
|
|
#endif
|
2017-03-21 10:44:12 +03:00
|
|
|
Maybe<AutoTimeDurationHelper> timeDurationHelper;
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
if (priority == EventPriority::Input) {
|
2017-03-21 10:44:12 +03:00
|
|
|
timeDurationHelper.emplace();
|
|
|
|
}
|
2018-03-06 12:19:19 +03:00
|
|
|
|
|
|
|
// The event starts to run, storing the timestamp.
|
|
|
|
bool recursiveEvent = false;
|
|
|
|
RefPtr<mozilla::PerformanceCounter> currentPerformanceCounter;
|
|
|
|
if (schedulerLoggingEnabled) {
|
|
|
|
recursiveEvent = mNestedEventLoopDepth > mCurrentEventLoopDepth;
|
|
|
|
mCurrentEventStart = mozilla::TimeStamp::Now();
|
|
|
|
mCurrentEvent = event;
|
|
|
|
mCurrentEventLoopDepth = mNestedEventLoopDepth;
|
|
|
|
mCurrentPerformanceCounter = GetPerformanceCounter(event);
|
|
|
|
currentPerformanceCounter = mCurrentPerformanceCounter;
|
|
|
|
}
|
2018-04-24 23:03:06 +03:00
|
|
|
|
2009-06-11 21:09:35 +04:00
|
|
|
event->Run();
|
2018-03-06 12:19:19 +03:00
|
|
|
|
|
|
|
// End of execution, we can send the duration for the group
|
|
|
|
if (schedulerLoggingEnabled) {
|
|
|
|
if (recursiveEvent) {
|
|
|
|
// If we're in a recursive call, reset the timer,
|
|
|
|
// so the parent gets its remaining execution time right.
|
|
|
|
mCurrentEventStart = mozilla::TimeStamp::Now();
|
|
|
|
mCurrentPerformanceCounter = currentPerformanceCounter;
|
|
|
|
} else {
|
|
|
|
// We're done with this dispatch
|
|
|
|
if (currentPerformanceCounter) {
|
|
|
|
mozilla::TimeDuration duration = TimeStamp::Now() - mCurrentEventStart;
|
|
|
|
currentPerformanceCounter->IncrementExecutionDuration(duration.ToMicroseconds());
|
|
|
|
}
|
|
|
|
mCurrentEvent = nullptr;
|
|
|
|
mCurrentEventLoopDepth = -1;
|
|
|
|
mCurrentPerformanceCounter = nullptr;
|
|
|
|
}
|
|
|
|
}
|
2014-05-27 11:15:35 +04:00
|
|
|
} else if (aMayWait) {
|
2013-02-08 09:54:20 +04:00
|
|
|
MOZ_ASSERT(ShuttingDown(),
|
|
|
|
"This should only happen when shutting down");
|
2009-06-11 21:09:35 +04:00
|
|
|
rv = NS_ERROR_UNEXPECTED;
|
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
2017-08-21 23:26:14 +03:00
|
|
|
NOTIFY_EVENT_OBSERVERS(EventQueue()->EventObservers(), AfterProcessNextEvent, (this, *aResult));
|
2010-11-19 01:19:19 +03:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
if (obs) {
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
obs->AfterProcessNextEvent(this, *aResult);
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-06-07 04:06:11 +04:00
|
|
|
|
2016-06-24 21:19:50 +03:00
|
|
|
if (callScriptObserver) {
|
|
|
|
if (mScriptObserver) {
|
|
|
|
mScriptObserver->AfterProcessTask(mNestedEventLoopDepth);
|
|
|
|
}
|
|
|
|
noJSAPI.reset();
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2012-10-24 02:26:36 +04:00
|
|
|
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
--mNestedEventLoopDepth;
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
return rv;
|
1999-04-06 01:02:24 +04:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
// nsISupportsPriority
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::GetPriority(int32_t* aPriority)
|
2000-11-30 08:24:53 +03:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
*aPriority = mPriority;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
2000-11-30 08:24:53 +03:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::SetPriority(int32_t aPriority)
|
1999-04-06 10:09:15 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(!mThread)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
// NSPR defines the following four thread priorities:
|
|
|
|
// PR_PRIORITY_LOW
|
|
|
|
// PR_PRIORITY_NORMAL
|
|
|
|
// PR_PRIORITY_HIGH
|
|
|
|
// PR_PRIORITY_URGENT
|
|
|
|
// We map the priority values defined on nsISupportsPriority to these values.
|
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
mPriority = aPriority;
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
PRThreadPriority pri;
|
|
|
|
if (mPriority <= PRIORITY_HIGHEST) {
|
|
|
|
pri = PR_PRIORITY_URGENT;
|
|
|
|
} else if (mPriority < PRIORITY_NORMAL) {
|
|
|
|
pri = PR_PRIORITY_HIGH;
|
|
|
|
} else if (mPriority > PRIORITY_NORMAL) {
|
|
|
|
pri = PR_PRIORITY_LOW;
|
|
|
|
} else {
|
|
|
|
pri = PR_PRIORITY_NORMAL;
|
|
|
|
}
|
2014-03-03 09:12:27 +04:00
|
|
|
// If chaos mode is active, retain the randomly chosen priority
|
2015-07-15 00:29:23 +03:00
|
|
|
if (!ChaosMode::isActive(ChaosFeature::ThreadScheduling)) {
|
2014-03-03 09:12:27 +04:00
|
|
|
PR_SetThreadPriority(mThread, pri);
|
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
return NS_OK;
|
1999-04-06 10:09:15 +04:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::AdjustPriority(int32_t aDelta)
|
1999-04-06 01:02:24 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
return SetPriority(mPriority + aDelta);
|
1999-04-06 01:02:24 +04:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
// nsIThreadInternal
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::GetObserver(nsIThreadObserver** aObs)
|
1999-06-13 07:30:38 +04:00
|
|
|
{
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
nsCOMPtr<nsIThreadObserver> obs = mEvents->GetObserver();
|
|
|
|
obs.forget(aObs);
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-06-13 07:30:38 +04:00
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::SetObserver(nsIThreadObserver* aObs)
|
1999-06-13 07:30:38 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(PR_GetCurrentThread() != mThread)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_NOT_SAME_THREAD;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
mEvents->SetObserver(aObs);
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
1999-06-13 07:30:38 +04:00
|
|
|
}
|
|
|
|
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
uint32_t
|
|
|
|
nsThread::RecursionDepth() const
|
2010-11-16 00:49:49 +03:00
|
|
|
{
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
MOZ_ASSERT(PR_GetCurrentThread() == mThread);
|
|
|
|
return mNestedEventLoopDepth;
|
2010-11-16 00:49:49 +03:00
|
|
|
}
|
|
|
|
|
2010-11-19 01:19:19 +03:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::AddObserver(nsIThreadObserver* aObserver)
|
2010-11-19 01:19:19 +03:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(!aObserver)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_INVALID_ARG;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
|
|
|
if (NS_WARN_IF(PR_GetCurrentThread() != mThread)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_NOT_SAME_THREAD;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2010-11-19 01:19:19 +03:00
|
|
|
|
2017-08-21 23:26:14 +03:00
|
|
|
EventQueue()->AddObserver(aObserver);
|
2010-11-19 01:19:19 +03:00
|
|
|
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThread::RemoveObserver(nsIThreadObserver* aObserver)
|
2010-11-19 01:19:19 +03:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(PR_GetCurrentThread() != mThread)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_NOT_SAME_THREAD;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2010-11-19 01:19:19 +03:00
|
|
|
|
2017-08-21 23:26:14 +03:00
|
|
|
EventQueue()->RemoveObserver(aObserver);
|
2010-11-19 01:19:19 +03:00
|
|
|
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
void
|
2016-09-14 16:47:32 +03:00
|
|
|
nsThread::SetScriptObserver(mozilla::CycleCollectedJSContext* aScriptObserver)
|
2012-10-24 02:26:36 +04:00
|
|
|
{
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
if (!aScriptObserver) {
|
|
|
|
mScriptObserver = nullptr;
|
|
|
|
return;
|
2012-10-24 02:26:36 +04:00
|
|
|
}
|
|
|
|
|
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.
2015-08-11 16:10:46 +03:00
|
|
|
MOZ_ASSERT(!mScriptObserver);
|
|
|
|
mScriptObserver = aScriptObserver;
|
2012-10-24 02:26:36 +04:00
|
|
|
}
|
|
|
|
|
2016-05-22 15:30:03 +03:00
|
|
|
void
|
|
|
|
nsThread::DoMainThreadSpecificProcessing(bool aReallyWait)
|
|
|
|
{
|
|
|
|
MOZ_ASSERT(mIsMainThread == MAIN_THREAD);
|
|
|
|
|
|
|
|
ipc::CancelCPOWs();
|
|
|
|
|
|
|
|
if (aReallyWait) {
|
|
|
|
HangMonitor::Suspend();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Fire a memory pressure notification, if one is pending.
|
|
|
|
if (!ShuttingDown()) {
|
|
|
|
MemoryPressureState mpPending = NS_GetPendingMemoryPressure();
|
|
|
|
if (mpPending != MemPressure_None) {
|
|
|
|
nsCOMPtr<nsIObserverService> os = services::GetObserverService();
|
|
|
|
|
|
|
|
if (os) {
|
2017-03-14 05:26:27 +03:00
|
|
|
// Use no-forward to prevent the notifications from being transferred to
|
|
|
|
// the children of this process.
|
2016-05-22 15:30:03 +03:00
|
|
|
os->NotifyObservers(nullptr, "memory-pressure",
|
2017-03-14 05:26:27 +03:00
|
|
|
mpPending == MemPressure_New ? u"low-memory-no-forward" :
|
|
|
|
u"low-memory-ongoing-no-forward");
|
2016-05-22 15:30:03 +03:00
|
|
|
} else {
|
|
|
|
NS_WARNING("Can't get observer service!");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ShuttingDown()) {
|
2016-06-21 21:45:25 +03:00
|
|
|
SaveMemoryReportNearOOM(ShouldSaveMemoryReport::kMaybeReport);
|
2016-05-22 15:30:03 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-23 01:12:43 +03:00
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThread::GetEventTarget(nsIEventTarget** aEventTarget)
|
|
|
|
{
|
|
|
|
nsCOMPtr<nsIEventTarget> target = this;
|
|
|
|
target.forget(aEventTarget);
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsIEventTarget*
|
|
|
|
nsThread::EventTarget()
|
|
|
|
{
|
|
|
|
return this;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsISerialEventTarget*
|
|
|
|
nsThread::SerialEventTarget()
|
|
|
|
{
|
|
|
|
return this;
|
|
|
|
}
|