This moves it near the cross-process `PContent` actor, and makes it more clear
that this actor is only intended to be used for DOM things.
Differential Revision: https://phabricator.services.mozilla.com/D80581
This moves it near the cross-process `PContent` actor, and makes it more clear
that this actor is only intended to be used for DOM things.
Differential Revision: https://phabricator.services.mozilla.com/D80581
We move OnStartRequest from PHttpChannel to PHttpBackgroundChannel, thus adjusting
message-metadata.ini
Depends on D76970
Differential Revision: https://phabricator.services.mozilla.com/D76971
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
There's no other change than definition changes. All callers are actually passing nsISerialEventTarget.
Depends on D80423
Differential Revision: https://phabricator.services.mozilla.com/D80424
To intercept COM IPC, we provide an `IChannelHook` interface to
`CoRegisterChannelHook`, which gives us notifications about COM IPC that we can
use to insert profiler markers. Note that `IChannelHook` is not documented on
MSDN, however it is defined in the SDK header files.
When the profiler is available, once XPCOM is up:
* If the profiler is active, we immediately register the channel hook;
* Otherwise we register an observer and hold off on registering the hook until
the profiler is started, at which point we register the hook and remove the
observer.
Differential Revision: https://phabricator.services.mozilla.com/D80053
To intercept COM IPC, we provide an `IChannelHook` interface to
`CoRegisterChannelHook`, which gives us notifications about COM IPC that we can
use to insert profiler markers. Note that `IChannelHook` is not documented on
MSDN, however it is defined in the SDK header files.
When the profiler is available, once XPCOM is up:
* If the profiler is active, we immediately register the channel hook;
* Otherwise we register an observer and hold off on registering the hook until
the profiler is started, at which point we register the hook and remove the
observer.
Differential Revision: https://phabricator.services.mozilla.com/D80053
The change to MessageChannel::Clear() makes mLink get cleared before
we call ~ThreadLink. This causes a race because Clear() is not
holding the monitor. To work around this, I introduced a new method
PrepareToDestroy() that handles the ThreadLink splitting. Once the
ThreadLinks are split, MessageChannel can clear mLink without a
race.
An alternative approach would be to hold the monitor in Clear()
before mLink is cleared, but then we'd end up acquiring the lock
when we didn't need to in the case where mLink is a ProcessLink.
Differential Revision: https://phabricator.services.mozilla.com/D79185
Keeping a list of ancestor principals in a LoadInfo object, that, at times,
exists in the content process, is not secure. Since ancestor principals are
only ever needed to create a list of frameAncestors, which, in turn, are only
ever accessed from the parent process, we can assemble lists of ancestor
principals and outer windowIDs whenever we are in the parent process and are
either 1) creating a LoadInfo object or 2) deserializing a LoadInfoArgs struct,
received from content process, into a LoadInfo object.
Differential Revision: https://phabricator.services.mozilla.com/D78406
The reply argument that gets passed in is a stack reference which is move
assigned into, so it doesn't make sense as a unique pointer, although the
code could be restructured to return a freshly allocated object instead.
This mostly just eliminates a spurious round trip from UniquePtr to *
and back. The bulk of the patch is renaming uses of |msg| to |aMsg|.
Differential Revision: https://phabricator.services.mozilla.com/D77908
Gcc and Clang dumps gcda files just before an exec** or fork functions.
With ccov enabled, we can dump using a SIGUSR1 but if we're in the middle of dump (because of exec** or fork)
then a gcda file can stay locked and then another process can try to get a lock on it for ever.
So to avoid such a situation, we remove the SIGUSR1 handler just before the fork an set it back just after.
Differential Revision: https://phabricator.services.mozilla.com/D78051
This is more standard, and uses about 4kb less memory when almost empty,
which seems to be the common case in an idle content process. This should save
around 66kb per content process.
The next patch will get ride of this thin wrapper and use nsDataHashtable
directly.
Differential Revision: https://phabricator.services.mozilla.com/D76985
This method is the same as Put(), except that it asserts that the item
is not already present. It also puts the key second. Make it compatible
by hoisting out the assert and reversing the arguments. We can use the
definition of Put() defined in an earlier patch.
Differential Revision: https://phabricator.services.mozilla.com/D77167
nsTHashtable::Remove doesn't assert if the item isn't present. Match that
behavior by removing the assert and putting it at all of the call sites.
This just turns IDMap::Remove into RemoveIfPresent, so merge them.
Differential Revision: https://phabricator.services.mozilla.com/D77166
This function is similar to the Put() method in nsTHashtable, but it lists the
key second and it asserts that the key is not already in the map. This patch
swaps the arguments and hoists the assertion out, where appropriate. Note that
there are a few places that were working around this assert, so for those places
don't include the assert.
Differential Revision: https://phabricator.services.mozilla.com/D77165
