This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
Using forget() to extract mMessage from MessageElement ends up going
from nsCOMPtr<T> to already_AddRefed<T> to nsCOMPtr<T>. For the second
step, the compiler can't tell that the already_AddRefed<T> came from a
canonical nsCOMPtr, so it calls Assert_NoQueryNeeded() in debug
builds. This in turn causes a QI, which does an AddRef. That is bad
because we're not on the main thread, and mMessage is
main-thread-only, so we get an assertion.
This patch works around that by using swap directly between two
nsCOMPtr<>, which avoids the Assert_NoQueryNeeded().
I called the method "swapMessage" rather than "swap" to emphasize that
we are not swapping the whole MessageElement, but just one part of
it. I find the existing forget() name to be confusing.
We don't need to reinterpret_cast when casting from void*, and we don't
need to reinterpret_cast when we're casting up and down a class
hierarchy. static_cast takes care of those cases just fine, and doesn't
scare the reader into thinking that nsTHashtable is doing something
unusual.
This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
This changeset replaces all of the
// char16_t[]
optional bytes someProperty = 1;
one- and two-byte string properties in the CoreDump.proto protobuf definition
file with:
oneof {
// char16_t[]
bytes someProperty = 1;
uint64 somePropertyRef = 2;
}
The first time the N^th unique string is serialized, then someProperty is used
and the full string is serialized in the protobuf message. All following times
that string is serialized, somePropertyRef is used and its value is N.
Among the other things, this also changes JS::ubi::Edge::name from a raw pointer
with commented rules about who does or doesn't own and should and shouldn't free
the raw pointer to a UniquePtr that enforces those rules rather than relying on
developers reading and obeying the rules in the comments.
This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
This moves the app-shipped system add-ons into <appdir>/features. I've created
a new directory provider location for this since it allows us to override the
location without allowing external apps to do so as would be the case with
prefs.
xptcstubs_arm mostly works on iOS but Apple's assembler is ridiculous so
the inline assembly for the SharedStub and the stub methods needs judicious
preprocessor use.
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.
Like the previous patch, this patch is a no-op change in terms of
functionality. It does, however, pave part of the way for forcing
clients of nsEventQueue to provide their own locking.
This patch is a no-op in terms of functionality. It ensures that we're
always holding nsThread's mutex when we touch mEvents, as dictated by
the comments. Putting this addition into its own patch will help make
the change to having nsEventQueue by guarded by a Mutex, rather than a
Monitor, somewhat clearer.
This is another case of an access to mEvents not being protected by
mLock. Future patches will make this locking requirement explicit in
nsChainedEventQueue, so we won't have problems like this. (Since
nsEventQueue has its own locking at this point, this omission didn't
matter much, but the omission will most certainly matter later.)
GetEvent was only called from one place, so it wasn't terribly useful as
an abstraction. It also broke the invariant that we protect accesses to
mEvents with mLock, as documented in nsThread.h. While upcoming patches
could have just updated GetEvent to do the necessary locking on its own,
it seemed just as easy to make the locking requirements at the callsite,
as will be done for other accesses to mEvents.
nsEventQueue's monitor does not require re-entrancy now that the monitor
is not externally visible. Since ReentrantMonitors require two separate
mutex lock/unlock pairs (one on entry, and one on exit), this cuts the
amount of locking nsEventQueue's methods do by half.
