The current code is a bit of a mess. This patch does the following.
- Changes the processing from backwards to forwards. This avoids the need for
all the `found` booleans, because if a flag is present multiple times, the
last one will naturally override.
- Tightens up the checking. It now doesn't use assertions, but instead returns
false if any of the options are missing arguments, or have malformed
arguments, or any of the mandatory flags are missing. (It assumes that
-appdir and -profile are optional.)
- Renames the loop variable `idx` as `i`.
- Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer.
- Avoids a redundant nsCString when handling -appdir.
The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It
holds the appModelUserId argument, which XRE_InitChildProcess() always expects
is present in the command. But it's only set to a non-empty value in
InitWindowsGroupID(), which is only called for plugin processes. So in lots of
cases the appModelUserId argument was missing, and a different argument would
be interpreted as the appModelUserId argument (seemingly without noticeable ill
effect).
The patch changes things to mGroupId defaults to "-", which means it's always
present in the command.
Note: all this explains why the old code for ContentProcess::Init() started
processing from argument aArgc, instead of aArgc-1 as you might expect -- it
had to read one extra arg in order to see the argument following -appdir,
because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId
argument even when that argument wasn't present. The new code for
ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId
fix ensures the appModelUserId argument is always present.
MozReview-Commit-ID: 8a8k6ABYMgo
--HG--
extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
Once we've figured out that some task needs to be reposted, there's no
reason to continue scanning the list to find other tasks that need to be
reposted, since the logic in this function just requires one task that
needs to be reposted.
This code isn't blocking anything, but it's dead and I don't think we
have any plans to use it.
MozReview-Commit-ID: KBoEfLceDns
--HG--
extra : rebase_source : 1eee3d961e249939f02d4cc40a707739eb2a596a
We're not using named shared memory, and supporting only anonymous
shared memory allows using other backends that are more compatible
with preventing a process from accessing any shared memory it wasn't
explicitly granted (i.e., sandboxing).
Specifically: SharedMemory::Open is removed; SharedMemory::Create no
longer takes a name, no longer has the open_existing option which doesn't
apply to anonymous memory, and no longer supports read-only memory
(anonymous memory which can never have been written isn't very useful).
This patch also fixes some comments in what remains of SharedMemory::Create.
MozReview-Commit-ID: 4kBrURtxq20
--HG--
extra : rebase_source : f6b1fb2fc79b6e9cdd251b3d9041036c0be503f9
This deletes some dead code and removes a dependency on the shared
memory object's name, which will be removed in the next patch (and is
always empty in our usage).
MozReview-Commit-ID: 1ub0nLCBucO
--HG--
extra : rebase_source : 6a29261e00b89773a2f2ace47303d9d9842c089b
This remotes the APZInputBridge interface over the PAPZInputBridge
protocol in the case of the GPU process, and makes the GPU process'
main thread act as the APZ controller thread in that process. If
there is no GPU process we continue as before and the APZInputBridge
interface implementation is the concrete APZCTreeManager instance
in the UI process.
The main changes in this patch are moving all the code associated with
these messages out of APZCTreeManager{Parent,Child} and into
APZInputBridge{Parent,Child}. APZCTreeManagerChild now returns an
APZInputBridgeChild instance via InputBridge(), instead of returning
itself. The SetControllerThread call in the GPU process is also updated.
MozReview-Commit-ID: M4AaIW1Q0h
--HG--
extra : rebase_source : e5a8f14e23be34229fe80a47f6789d19b19e0a9f
They are not yet fully async because ContentParent::InitInternal calls
OtherPid(), which will block until the process is spawned. Deferring the calls
to OtherPid() will be a subject of a follow up patch.
MozReview-Commit-ID: 4TFkMpdQtRw
--HG--
extra : rebase_source : 3e7567679ae04aa4c04ea6f6c146e70417e7ce05
This will let us manipulate it from multiple threads in a future patch.
MozReview-Commit-ID: 2AOgho8SEX9
--HG--
extra : rebase_source : 49e7d82b38e6f7b7eb9f6cb7c61a2b41d34f2bdc
This code is unused now that ReadLockDescriptors are not sent in layer transactions.
--HG--
extra : rebase_source : 8cd25541b22c3151e2dbd2f8ea6d1119e2f26c94
extra : source : 99a2d26d1ba82ad34a6c27641500a424cda015c3
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
This changes the lifecycle and API for TextureReadLock to fix file descriptor exhaustion
crashes. These changes are partially superficial and mostly align the API of TextureReadLocks
with their actual usage.
The changes are:
1. Create the TextureReadLock in the TextureClient constructor so it's available before IPC creation
a. This is superficial as EnableReadLock was always called before IPC creation
2. Send the ReadLockDescriptor in the PTextureConstructor message and close the file handle
3. Receive the ReadLockDescriptor in TextureHost and close the file handle
4. Send a boolean flag in layer transactions if the texture is read locked instead of a descriptor
5. Use a boolean flag in TextureHost to determine if the ReadLock must be unlocked instead of a nullptr
I believe that we can remove the InitReadLocks code from LayerTransaction as that was added to
prevent file descriptor limits in IPDL messages and is no longer needed with this change. But
that is a non-essential change and this patch is already big enough.
MozReview-Commit-ID: DzHujrOQejH
--HG--
extra : rebase_source : 3bdd7c9bc8edfdc386faad8a9e59ad7dc18ed91d
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 596f590443f727d1a79582202eed122f79ae85cf
Because Interceptors disable COM garbage collection to improve performance, they never receive Release calls from remote clients.
If the object can be shut down while clients still hold a reference, this function can be used to force COM to disconnect all remote connections (using CoDisconnectObject) and thus release the associated references to the Interceptor, its target and any objects associated with the HandlerProvider.
A HandlerProvider::DisconnectHandlerRemotes method also had to be added to allow HandlerProviders to disconnect clients for their own objects.
MozReview-Commit-ID: JaxEkOtrP1M
--HG--
extra : rebase_source : bc7a4ab79458eaaddcef8df74ff4d6f685fbfdce
extra : histedit_source : 087f17f09a0c0e1c8e3b5f6d9690f331c15f0b95
COM queries for special interfaces such as IFastRundown when creating a marshaler.
We don't want these being dispatched to the main thread, since this would cause a deadlock on mStdMarshalMutex if the main thread is also querying for IMarshal.
MozReview-Commit-ID: EQcN8Zhewjh
--HG--
extra : rebase_source : 40c39edce139f66fdb43b539b1d6fb0acb00d755
This is important as these includes are often used to define ParamTraits
implementations which are needed to serialize struct members and
parameters. The place where the code which uses these implementations
will be moving from the protocol where they are used to the file where
the structs are defined, which means we need to includes these files
there.
MozReview-Commit-ID: H1wqgyv5mel
Bob Owen
Nathan Froyd
Tom Schuster
Nicholas Nethercote
Jed Davis
Miko Mynttinen
Ted Mielczarek
Kartikaya Gupta
Stephen A Pohl
Alex Gaynor
Sylvestre Ledru
shindli
Ryan Hunt
Jonathan Kingston
Coroiu Cristina
Bogdan Tara
Jim Chen
Dorel Luca
Honza Bambas
Csoregi Natalia
Christoph Diehl
Cosmin Sabou
Nika Layzell
James Teh