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/. */
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
#include "nsIClassInfoImpl.h"
|
|
|
|
#include "nsThreadPool.h"
|
|
|
|
#include "nsThreadManager.h"
|
|
|
|
#include "nsThread.h"
|
|
|
|
#include "nsMemory.h"
|
|
|
|
#include "nsAutoPtr.h"
|
|
|
|
#include "prinrval.h"
|
2015-05-19 21:15:34 +03:00
|
|
|
#include "mozilla/Logging.h"
|
2015-10-06 05:00:59 +03:00
|
|
|
#include "nsThreadSyncDispatch.h"
|
2006-05-10 21:30:15 +04:00
|
|
|
|
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 sThreadPoolLog("nsThreadPool");
|
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(sThreadPoolLog, mozilla::LogLevel::Debug, args)
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
// DESIGN:
|
|
|
|
// o Allocate anonymous threads.
|
|
|
|
// o Use nsThreadPool::Run as the main routine for each thread.
|
|
|
|
// o Each thread waits on the event queue's monitor, checking for
|
|
|
|
// pending events and rescheduling itself as an idle thread.
|
|
|
|
|
|
|
|
#define DEFAULT_THREAD_LIMIT 4
|
|
|
|
#define DEFAULT_IDLE_THREAD_LIMIT 1
|
|
|
|
#define DEFAULT_IDLE_THREAD_TIMEOUT PR_SecondsToInterval(60)
|
|
|
|
|
2013-07-19 06:31:26 +04:00
|
|
|
NS_IMPL_ADDREF(nsThreadPool)
|
|
|
|
NS_IMPL_RELEASE(nsThreadPool)
|
2013-10-11 00:42:16 +04:00
|
|
|
NS_IMPL_CLASSINFO(nsThreadPool, nullptr, nsIClassInfo::THREADSAFE,
|
2010-06-22 20:59:57 +04:00
|
|
|
NS_THREADPOOL_CID)
|
2014-04-27 11:06:00 +04:00
|
|
|
NS_IMPL_QUERY_INTERFACE_CI(nsThreadPool, nsIThreadPool, nsIEventTarget,
|
|
|
|
nsIRunnable)
|
|
|
|
NS_IMPL_CI_INTERFACE_GETTER(nsThreadPool, nsIThreadPool, nsIEventTarget)
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
nsThreadPool::nsThreadPool()
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
: mMutex("[nsThreadPool.mMutex]")
|
|
|
|
, mEvents(mMutex)
|
2015-09-03 22:38:28 +03:00
|
|
|
, mThreadLimit(DEFAULT_THREAD_LIMIT)
|
2006-05-10 21:30:15 +04:00
|
|
|
, mIdleThreadLimit(DEFAULT_IDLE_THREAD_LIMIT)
|
|
|
|
, mIdleThreadTimeout(DEFAULT_IDLE_THREAD_TIMEOUT)
|
|
|
|
, mIdleCount(0)
|
2014-02-18 11:11:56 +04:00
|
|
|
, mStackSize(nsIThreadManager::DEFAULT_STACK_SIZE)
|
2011-10-17 18:59:28 +04:00
|
|
|
, mShutdown(false)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2015-09-03 22:38:28 +03:00
|
|
|
LOG(("THRD-P(%p) constructor!!!\n", this));
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
nsThreadPool::~nsThreadPool()
|
|
|
|
{
|
2013-10-23 22:21:37 +04:00
|
|
|
// Threads keep a reference to the nsThreadPool until they return from Run()
|
|
|
|
// after removing themselves from mThreads.
|
|
|
|
MOZ_ASSERT(mThreads.IsEmpty());
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
nsresult
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::PutEvent(nsIRunnable* aEvent)
|
2015-07-10 06:21:46 +03:00
|
|
|
{
|
|
|
|
nsCOMPtr<nsIRunnable> event(aEvent);
|
2016-01-05 06:35:17 +03:00
|
|
|
return PutEvent(event.forget(), 0);
|
2015-07-10 06:21:46 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
nsresult
|
2016-01-05 06:35:17 +03:00
|
|
|
nsThreadPool::PutEvent(already_AddRefed<nsIRunnable>&& aEvent, uint32_t aFlags)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
|
|
|
// Avoid spawning a new thread while holding the event queue lock...
|
2014-02-18 02:53:53 +04:00
|
|
|
|
2011-09-29 10:19:26 +04:00
|
|
|
bool spawnThread = false;
|
2014-02-18 02:53:53 +04:00
|
|
|
uint32_t stackSize = 0;
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2015-09-21 11:34:51 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2014-06-21 14:26:43 +04:00
|
|
|
if (NS_WARN_IF(mShutdown)) {
|
|
|
|
return NS_ERROR_NOT_AVAILABLE;
|
|
|
|
}
|
2013-10-25 08:40:39 +04:00
|
|
|
LOG(("THRD-P(%p) put [%d %d %d]\n", this, mIdleCount, mThreads.Count(),
|
2006-05-10 21:30:15 +04:00
|
|
|
mThreadLimit));
|
2014-05-27 11:15:35 +04:00
|
|
|
MOZ_ASSERT(mIdleCount <= (uint32_t)mThreads.Count(), "oops");
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
// Make sure we have a thread to service this event.
|
2015-05-09 02:32:30 +03:00
|
|
|
if (mThreads.Count() < (int32_t)mThreadLimit &&
|
2016-01-05 06:35:17 +03:00
|
|
|
!(aFlags & NS_DISPATCH_TAIL) &&
|
2015-05-09 02:32:30 +03:00
|
|
|
// Spawn a new thread if we don't have enough idle threads to serve
|
|
|
|
// pending events immediately.
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
mEvents.Count(lock) >= mIdleCount) {
|
2011-10-17 18:59:28 +04:00
|
|
|
spawnThread = true;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2013-10-25 08:40:39 +04:00
|
|
|
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
mEvents.PutEvent(Move(aEvent), lock);
|
2014-02-18 02:53:53 +04:00
|
|
|
stackSize = mStackSize;
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
LOG(("THRD-P(%p) put [spawn=%d]\n", this, spawnThread));
|
2014-05-27 11:15:35 +04:00
|
|
|
if (!spawnThread) {
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2013-10-25 08:40:39 +04:00
|
|
|
nsCOMPtr<nsIThread> thread;
|
|
|
|
nsThreadManager::get()->NewThread(0,
|
2014-02-18 02:53:53 +04:00
|
|
|
stackSize,
|
2013-10-25 08:40:39 +04:00
|
|
|
getter_AddRefs(thread));
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(!thread)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_UNEXPECTED;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2013-10-25 08:40:39 +04:00
|
|
|
bool killThread = false;
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2014-05-27 11:15:35 +04:00
|
|
|
if (mThreads.Count() < (int32_t)mThreadLimit) {
|
2013-10-25 08:40:39 +04:00
|
|
|
mThreads.AppendObject(thread);
|
|
|
|
} else {
|
|
|
|
killThread = true; // okay, we don't need this thread anymore
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
2013-10-25 08:40:39 +04:00
|
|
|
}
|
|
|
|
LOG(("THRD-P(%p) put [%p kill=%d]\n", this, thread.get(), killThread));
|
|
|
|
if (killThread) {
|
2015-09-15 04:24:43 +03:00
|
|
|
// We never dispatched any events to the thread, so we can shut it down
|
|
|
|
// asynchronously without worrying about anything.
|
2016-02-01 20:44:52 +03:00
|
|
|
ShutdownThread(thread);
|
2013-10-25 08:40:39 +04:00
|
|
|
} else {
|
|
|
|
thread->Dispatch(this, NS_DISPATCH_NORMAL);
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::ShutdownThread(nsIThread* aThread)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
LOG(("THRD-P(%p) shutdown async [%p]\n", this, aThread));
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2016-02-01 20:44:52 +03:00
|
|
|
// This is either called by a threadpool thread that is out of work, or
|
|
|
|
// a thread that attempted to create a threadpool thread and raced in
|
|
|
|
// such a way that the newly created thread is no longer necessary.
|
|
|
|
// In the first case, we must go to another thread to shut aThread down
|
|
|
|
// (because it is the current thread). In the second case, we cannot
|
|
|
|
// synchronously shut down the current thread (because then Dispatch() would
|
|
|
|
// spin the event loop, and that could blow up the world), and asynchronous
|
|
|
|
// shutdown requires this thread have an event loop (and it may not, see bug
|
|
|
|
// 10204784). The simplest way to cover all cases is to asynchronously
|
|
|
|
// shutdown aThread from the main thread.
|
2016-04-29 15:21:16 +03:00
|
|
|
nsCOMPtr<nsIRunnable> r = NS_NewRunnableMethod(aThread,
|
|
|
|
&nsIThread::AsyncShutdown);
|
|
|
|
NS_DispatchToMainThread(r);
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
2013-10-25 08:40:39 +04:00
|
|
|
NS_IMETHODIMP
|
2006-05-10 21:30:15 +04:00
|
|
|
nsThreadPool::Run()
|
|
|
|
{
|
2012-06-12 21:06:20 +04:00
|
|
|
mThreadNaming.SetThreadPoolName(mName);
|
|
|
|
|
2015-09-03 22:38:28 +03:00
|
|
|
LOG(("THRD-P(%p) enter %s\n", this, mName.BeginReading()));
|
|
|
|
|
2013-10-25 08:40:39 +04:00
|
|
|
nsCOMPtr<nsIThread> current;
|
|
|
|
nsThreadManager::get()->GetCurrentThread(getter_AddRefs(current));
|
|
|
|
|
|
|
|
bool shutdownThreadOnExit = false;
|
|
|
|
bool exitThread = false;
|
|
|
|
bool wasIdle = false;
|
|
|
|
PRIntervalTime idleSince;
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2008-08-12 04:01:47 +04:00
|
|
|
nsCOMPtr<nsIThreadPoolListener> listener;
|
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2008-08-12 04:01:47 +04:00
|
|
|
listener = mListener;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (listener) {
|
|
|
|
listener->OnThreadCreated();
|
|
|
|
}
|
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
do {
|
|
|
|
nsCOMPtr<nsIRunnable> event;
|
|
|
|
{
|
2015-09-21 11:34:51 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
|
|
|
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
if (!mEvents.GetPendingEvent(getter_AddRefs(event), lock)) {
|
2006-05-10 21:30:15 +04:00
|
|
|
PRIntervalTime now = PR_IntervalNow();
|
|
|
|
PRIntervalTime timeout = PR_MillisecondsToInterval(mIdleThreadTimeout);
|
|
|
|
|
|
|
|
// If we are shutting down, then don't keep any idle threads
|
|
|
|
if (mShutdown) {
|
2011-10-17 18:59:28 +04:00
|
|
|
exitThread = true;
|
2006-05-10 21:30:15 +04:00
|
|
|
} else {
|
|
|
|
if (wasIdle) {
|
|
|
|
// if too many idle threads or idle for too long, then bail.
|
2015-11-18 23:03:17 +03:00
|
|
|
if (mIdleCount > mIdleThreadLimit ||
|
|
|
|
(mIdleThreadTimeout != UINT32_MAX && (now - idleSince) >= timeout)) {
|
2011-10-17 18:59:28 +04:00
|
|
|
exitThread = true;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
} else {
|
|
|
|
// if would be too many idle threads...
|
|
|
|
if (mIdleCount == mIdleThreadLimit) {
|
2011-10-17 18:59:28 +04:00
|
|
|
exitThread = true;
|
2006-05-10 21:30:15 +04:00
|
|
|
} else {
|
|
|
|
++mIdleCount;
|
|
|
|
idleSince = now;
|
2011-10-17 18:59:28 +04:00
|
|
|
wasIdle = true;
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (exitThread) {
|
2014-05-27 11:15:35 +04:00
|
|
|
if (wasIdle) {
|
2006-05-10 21:30:15 +04:00
|
|
|
--mIdleCount;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2013-10-25 08:40:39 +04:00
|
|
|
shutdownThreadOnExit = mThreads.RemoveObject(current);
|
2006-05-10 21:30:15 +04:00
|
|
|
} else {
|
|
|
|
PRIntervalTime delta = timeout - (now - idleSince);
|
2015-09-03 22:38:28 +03:00
|
|
|
LOG(("THRD-P(%p) %s waiting [%d]\n", this, mName.BeginReading(), delta));
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
mEvents.Wait(delta);
|
2015-09-03 22:38:28 +03:00
|
|
|
LOG(("THRD-P(%p) done waiting\n", this));
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
} else if (wasIdle) {
|
2011-10-17 18:59:28 +04:00
|
|
|
wasIdle = false;
|
2006-05-10 21:30:15 +04:00
|
|
|
--mIdleCount;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (event) {
|
2015-09-03 22:38:28 +03:00
|
|
|
LOG(("THRD-P(%p) %s running [%p]\n", this, mName.BeginReading(), event.get()));
|
2006-05-10 21:30:15 +04:00
|
|
|
event->Run();
|
|
|
|
}
|
|
|
|
} while (!exitThread);
|
|
|
|
|
2008-08-12 04:01:47 +04:00
|
|
|
if (listener) {
|
|
|
|
listener->OnThreadShuttingDown();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (shutdownThreadOnExit) {
|
2006-05-10 21:30:15 +04:00
|
|
|
ShutdownThread(current);
|
2008-08-12 04:01:47 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
|
|
|
LOG(("THRD-P(%p) leave\n", this));
|
2013-10-25 08:40:39 +04:00
|
|
|
return NS_OK;
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2015-07-10 06:21:46 +03:00
|
|
|
nsThreadPool::DispatchFromScript(nsIRunnable* aEvent, uint32_t aFlags)
|
|
|
|
{
|
|
|
|
nsCOMPtr<nsIRunnable> event(aEvent);
|
|
|
|
return Dispatch(event.forget(), aFlags);
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThreadPool::Dispatch(already_AddRefed<nsIRunnable>&& aEvent, uint32_t aFlags)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2015-07-10 06:21:46 +03:00
|
|
|
LOG(("THRD-P(%p) dispatch [%p %x]\n", this, /* XXX aEvent*/ nullptr, aFlags));
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(mShutdown)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_NOT_AVAILABLE;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
if (aFlags & DISPATCH_SYNC) {
|
2006-05-10 21:30:15 +04:00
|
|
|
nsCOMPtr<nsIThread> thread;
|
|
|
|
nsThreadManager::get()->GetCurrentThread(getter_AddRefs(thread));
|
2014-05-27 11:15:35 +04:00
|
|
|
if (NS_WARN_IF(!thread)) {
|
2013-11-20 01:27:37 +04:00
|
|
|
return NS_ERROR_NOT_AVAILABLE;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<nsThreadSyncDispatch> wrapper =
|
2015-07-10 06:21:46 +03:00
|
|
|
new nsThreadSyncDispatch(thread, Move(aEvent));
|
2006-05-10 21:30:15 +04:00
|
|
|
PutEvent(wrapper);
|
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
while (wrapper->IsPending()) {
|
2006-05-10 21:30:15 +04:00
|
|
|
NS_ProcessNextEvent(thread);
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
} else {
|
2016-03-15 08:12:27 +03:00
|
|
|
NS_ASSERTION(aFlags == NS_DISPATCH_NORMAL ||
|
|
|
|
aFlags == NS_DISPATCH_TAIL, "unexpected dispatch flags");
|
2016-01-05 06:35:17 +03:00
|
|
|
PutEvent(Move(aEvent), aFlags);
|
2006-05-10 21:30:15 +04:00
|
|
|
}
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::IsOnCurrentThread(bool* aResult)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2014-06-21 14:26:43 +04:00
|
|
|
if (NS_WARN_IF(mShutdown)) {
|
|
|
|
return NS_ERROR_NOT_AVAILABLE;
|
|
|
|
}
|
|
|
|
|
2014-02-18 02:53:52 +04:00
|
|
|
nsIThread* thread = NS_GetCurrentThread();
|
2014-02-18 11:11:56 +04:00
|
|
|
for (uint32_t i = 0; i < static_cast<uint32_t>(mThreads.Count()); ++i) {
|
2014-02-18 02:53:52 +04:00
|
|
|
if (mThreads[i] == thread) {
|
2014-05-27 11:15:35 +04:00
|
|
|
*aResult = true;
|
2014-02-18 02:53:52 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
}
|
2014-05-27 11:15:35 +04:00
|
|
|
*aResult = false;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThreadPool::Shutdown()
|
|
|
|
{
|
2013-10-25 08:40:39 +04:00
|
|
|
nsCOMArray<nsIThread> threads;
|
2008-08-12 04:01:47 +04:00
|
|
|
nsCOMPtr<nsIThreadPoolListener> listener;
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2011-10-17 18:59:28 +04:00
|
|
|
mShutdown = true;
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
mEvents.NotifyAll();
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2013-10-25 08:40:39 +04:00
|
|
|
threads.AppendObjects(mThreads);
|
|
|
|
mThreads.Clear();
|
|
|
|
|
2008-08-12 04:01:47 +04:00
|
|
|
// Swap in a null listener so that we release the listener at the end of
|
|
|
|
// this method. The listener will be kept alive as long as the other threads
|
|
|
|
// that were created when it was set.
|
|
|
|
mListener.swap(listener);
|
2013-10-24 00:31:15 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
|
2013-10-25 08:40:39 +04:00
|
|
|
// It's important that we shutdown the threads while outside the event queue
|
|
|
|
// monitor. Otherwise, we could end up dead-locking.
|
|
|
|
|
2014-05-27 11:15:35 +04:00
|
|
|
for (int32_t i = 0; i < threads.Count(); ++i) {
|
2013-10-25 08:40:39 +04:00
|
|
|
threads[i]->Shutdown();
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2013-10-25 08:40:39 +04:00
|
|
|
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::GetThreadLimit(uint32_t* aValue)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
*aValue = mThreadLimit;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::SetThreadLimit(uint32_t aValue)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2015-09-03 22:38:28 +03:00
|
|
|
LOG(("THRD-P(%p) thread limit [%u]\n", this, aValue));
|
2014-05-27 11:15:35 +04:00
|
|
|
mThreadLimit = aValue;
|
|
|
|
if (mIdleThreadLimit > mThreadLimit) {
|
2006-05-10 21:30:15 +04:00
|
|
|
mIdleThreadLimit = mThreadLimit;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2013-05-16 20:02:46 +04:00
|
|
|
|
2013-10-25 08:40:39 +04:00
|
|
|
if (static_cast<uint32_t>(mThreads.Count()) > mThreadLimit) {
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
mEvents.NotifyAll(); // wake up threads so they observe this change
|
2013-05-16 20:02:46 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::GetIdleThreadLimit(uint32_t* aValue)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
*aValue = mIdleThreadLimit;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::SetIdleThreadLimit(uint32_t aValue)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2015-09-03 22:38:28 +03:00
|
|
|
LOG(("THRD-P(%p) idle thread limit [%u]\n", this, aValue));
|
2014-05-27 11:15:35 +04:00
|
|
|
mIdleThreadLimit = aValue;
|
|
|
|
if (mIdleThreadLimit > mThreadLimit) {
|
2006-05-10 21:30:15 +04:00
|
|
|
mIdleThreadLimit = mThreadLimit;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2013-05-16 20:02:46 +04:00
|
|
|
|
|
|
|
// Do we need to kill some idle threads?
|
|
|
|
if (mIdleCount > mIdleThreadLimit) {
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
mEvents.NotifyAll(); // wake up threads so they observe this change
|
2013-05-16 20:02:46 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::GetIdleThreadTimeout(uint32_t* aValue)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
2014-05-27 11:15:35 +04:00
|
|
|
*aValue = mIdleThreadTimeout;
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::SetIdleThreadTimeout(uint32_t aValue)
|
2006-05-10 21:30:15 +04:00
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2013-05-16 20:02:46 +04:00
|
|
|
uint32_t oldTimeout = mIdleThreadTimeout;
|
2014-05-27 11:15:35 +04:00
|
|
|
mIdleThreadTimeout = aValue;
|
2013-05-16 20:02:46 +04:00
|
|
|
|
|
|
|
// Do we need to notify any idle threads that their sleep time has shortened?
|
|
|
|
if (mIdleThreadTimeout < oldTimeout && mIdleCount > 0) {
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
mEvents.NotifyAll(); // wake up threads so they observe this change
|
2013-05-16 20:02:46 +04:00
|
|
|
}
|
2006-05-10 21:30:15 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
2008-08-12 04:01:47 +04:00
|
|
|
|
2014-02-18 02:53:53 +04:00
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::GetThreadStackSize(uint32_t* aValue)
|
2014-02-18 02:53:53 +04:00
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2014-05-27 11:15:35 +04:00
|
|
|
*aValue = mStackSize;
|
2014-02-18 02:53:53 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2014-05-27 11:15:35 +04:00
|
|
|
nsThreadPool::SetThreadStackSize(uint32_t aValue)
|
2014-02-18 02:53:53 +04:00
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2014-05-27 11:15:35 +04:00
|
|
|
mStackSize = aValue;
|
2014-02-18 02:53:53 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2008-08-12 04:01:47 +04:00
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThreadPool::GetListener(nsIThreadPoolListener** aListener)
|
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2008-08-12 04:01:47 +04:00
|
|
|
NS_IF_ADDREF(*aListener = mListener);
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThreadPool::SetListener(nsIThreadPoolListener* aListener)
|
|
|
|
{
|
|
|
|
nsCOMPtr<nsIThreadPoolListener> swappedListener(aListener);
|
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2008-08-12 04:01:47 +04:00
|
|
|
mListener.swap(swappedListener);
|
|
|
|
}
|
|
|
|
return NS_OK;
|
|
|
|
}
|
2012-06-12 21:06:20 +04:00
|
|
|
|
|
|
|
NS_IMETHODIMP
|
|
|
|
nsThreadPool::SetName(const nsACString& aName)
|
|
|
|
{
|
|
|
|
{
|
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 12:13:09 +03:00
|
|
|
MutexAutoLock lock(mMutex);
|
2014-05-27 11:15:35 +04:00
|
|
|
if (mThreads.Count()) {
|
2012-06-12 21:06:20 +04:00
|
|
|
return NS_ERROR_NOT_AVAILABLE;
|
2014-05-27 11:15:35 +04:00
|
|
|
}
|
2012-06-12 21:06:20 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
mName = aName;
|
|
|
|
return NS_OK;
|
|
|
|
}
|