The stack from crash report suggests that ChildImpl was deleted at the end of function GetOrCreateSocketActorForCurrentThread(). This only happens when SendInitBackground failed, so we have to close the IPC channel before ChildImpl getting destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D40838
--HG--
extra : moz-landing-system : lando
The new StaticLocalAutoPtr smart pointer has a trivial destructor, so we will
either properly clean up this data or leak it on process shutdown. Either way,
we will not destroy it in a way that the underlying type does not support.
Differential Revision: https://phabricator.services.mozilla.com/D40842
--HG--
extra : moz-landing-system : lando
The new StaticLocalAutoPtr smart pointer has a trivial destructor, so we will
either properly clean up this data or leak it on process shutdown. Either way,
we will not destroy it in a way that the underlying type does not support.
Differential Revision: https://phabricator.services.mozilla.com/D40842
--HG--
extra : moz-landing-system : lando
ipc_message_utils.h defines IPDLParamTraits on windows for some things like
HWND and HANDLE. However, it doesn't directly include windows.h on Windows to
include them. All other usages seem to rely on including base/process.h, which
does include windows.h and adds the appropriate typedefs.
Differential Revision: https://phabricator.services.mozilla.com/D35089
--HG--
extra : moz-landing-system : lando
This takes the approach of directly tying the `AddRef()` and `Release()` calls
on the underlying actor object to the lifecycle of the ActorLifecycleProxy
object, by adding another virtual `ActorAlloc()` method as the counterpart to
`ActorDealloc()`.
The changes to the methods called from C++ are relatively minimal:
1. The `SendPFooConstructor(...)` methods have the same signature, but now will
AddRef() internally (through `ActorAlloc()`), so an `do_AddRef(foo).take()`
isn't needed. Same with the `{Bind,Open}PFooEndpoint` methods.
This was done to reduce the number of invasive internal changes in the
codegen which were required to pipe a passed-in `already_AddRefed` to the
underlying `ActorLifecycleProxy` which is created by generic code.
2. The `AllocPFoo{Parent,Child}` methods have been modified to return an
`already_AddRefed` by default, and the callsites will store the result in a
`RefPtr<T>` if the type is refcounted.
3. No `DeallocPFoo...` method is called anymore. Unfortunately due to
devirtualization, it won't be an error if an unused method is still present,
though it won't be called.
Differential Revision: https://phabricator.services.mozilla.com/D39502
--HG--
extra : moz-landing-system : lando
The syntax for the new construct looks like the following, and re-uses the
refcounted keyword from refcounted using statements:
async refcounted protocol PFoo { ... }
Differential Revision: https://phabricator.services.mozilla.com/D39501
--HG--
extra : moz-landing-system : lando
The previous behaviour of failing unconditionally was performed as, during
shutdown, the channel could become unable to send without worker threads having
a chance to react. This change keeps that behaviour, isolating async message
senders from impending IPC shutdown, while performing expected actor teardown if
the manager actor has already been destroyed, and should no longer send messages.
An alternate behaviour here could be to crash if !Manager()->CanSend(). That
behaviour may be preferable if a sufficient number of callsites don't check the
return value of the `SendPFooConstructor()` method.
Differential Revision: https://phabricator.services.mozilla.com/D39534
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Until now we asserted that EnsureMTA was being called from the main thread
unless the current thread was already in the MTA.
This patch makes MTA thread initialization thread-safe by using a C++11
"magic static," thus allowing EnsureMTA to be safely invoked from any thread.
Differential Revision: https://phabricator.services.mozilla.com/D38422
--HG--
extra : moz-landing-system : lando
At the moment, this shouldn't make any difference because we only ever
launch one child process on android.
Differential Revision: https://phabricator.services.mozilla.com/D38244
--HG--
extra : moz-landing-system : lando
Now that UniqueFileHandle can be used more widely, and with
ipc::FileDescriptor being essentially a copyable UniqueFileHandle, it
makes sense to add a move constructor and a "forget"-like method to
convert between them when needed.
Depends on D26737
Differential Revision: https://phabricator.services.mozilla.com/D26738
--HG--
extra : moz-landing-system : lando
I'm not convinced the current comment about being race-free is accurate
in context of the launcher pool. It probably _is_ correct under this
patch, because ProcessLaunchers should only be constructed on a single
thread, but it's easy enough just to make it atomic.
Hopefully moving the timestamp doesn't perturb telemetry too much.
Differential Revision: https://phabricator.services.mozilla.com/D37305
--HG--
extra : moz-landing-system : lando
This is intended to facilitate future work to break up
PerformAsyncLaunch into asynchronous pieces. It also aims to fix some
raciness around access to state in the GeckoChildProcessHost instance.
There appears to be at least one data race in the existing code, in which
OpenPrivilegedHandle are run on both the launcher thread and the IO
thread without synchronization.
Differential Revision: https://phabricator.services.mozilla.com/D36539
--HG--
extra : moz-landing-system : lando
Having to namespace these into GeckoChildProcessHost is annoying. The
|using| declarations help to some extent, but it's easier to just put
them in mozilla::ipc.
Differential Revision: https://phabricator.services.mozilla.com/D36538
--HG--
extra : moz-landing-system : lando
