gecko-dev/dom/ipc/ContentProcess.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

52 строки
1.4 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
2012-05-21 15:12:37 +04:00
* 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/. */
#ifndef dom_tabs_ContentThread_h
#define dom_tabs_ContentThread_h 1
#include "mozilla/ipc/ProcessChild.h"
#include "mozilla/ipc/ScopedXREEmbed.h"
#include "ContentChild.h"
#if defined(XP_WIN)
Bug 1400344: Rename mscom::MainThreadRuntime to mscom::ProcessRuntime and make it aware of Win32k lockdown and of multiple instantiations; r=Jamie This patch takes care of a bunch of issues and does some cleanup: * We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter is a more accurate name going forward. * We make ProcessRuntime aware of the Win32k Lockdown process mitigation policy. When Win32k is disabled, we perform process-wide COM initialization in the multi-threaded apartment (since we cannot create an STA window). * We refactor the mscom apartment region stuff to enable the Win32k lockdown pieces in ProcessRuntime. * We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that ProcessRuntime is usable outside of xul.dll (I will be needing it for the launcher process). * Another thing that might happen with the launcher process is that, under error conditions in the launcher, we create a ProcessRuntime object on a background thread for the purposes of telemetry logging, but we also allow the main thread to proceed to start as the browser. This could result in a scenario where the main thread, as the browser process, is attempting to instantiate its ProcessRuntime and ends up racing with the launcher process's telemetry thread which has its own ProcessRuntime. To account for this situation, we add mutual exclusion to the process-wide initialization code. We host this part inside mozglue since that state is shared between both firefox.exe and xul.dll. * We clean up ProcessRuntime::InitializeSecurity by using Vector to set up the EXPLICIT_ACCESS entries. * We remove mscom::MainThreadClientInfo and replace it with a direct call to CoGetCallerTID * We revise all references to this class to use the new name. Differential Revision: https://phabricator.services.mozilla.com/D19551 --HG-- rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h extra : moz-landing-system : lando
2019-02-14 21:56:20 +03:00
# include "mozilla/mscom/ProcessRuntime.h"
#endif
namespace mozilla {
namespace dom {
/**
* ContentProcess is a singleton on the content process which represents
* the main thread where tab instances live.
*/
class ContentProcess : public mozilla::ipc::ProcessChild {
typedef mozilla::ipc::ProcessChild ProcessChild;
public:
explicit ContentProcess(ProcessId aParentPid) : ProcessChild(aParentPid) {}
~ContentProcess() {}
virtual bool Init(int aArgc, char* aArgv[]) override;
virtual void CleanUp() override;
private:
ContentChild mContent;
mozilla::ipc::ScopedXREEmbed mXREEmbed;
#if defined(XP_WIN)
// This object initializes and configures COM.
Bug 1400344: Rename mscom::MainThreadRuntime to mscom::ProcessRuntime and make it aware of Win32k lockdown and of multiple instantiations; r=Jamie This patch takes care of a bunch of issues and does some cleanup: * We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter is a more accurate name going forward. * We make ProcessRuntime aware of the Win32k Lockdown process mitigation policy. When Win32k is disabled, we perform process-wide COM initialization in the multi-threaded apartment (since we cannot create an STA window). * We refactor the mscom apartment region stuff to enable the Win32k lockdown pieces in ProcessRuntime. * We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that ProcessRuntime is usable outside of xul.dll (I will be needing it for the launcher process). * Another thing that might happen with the launcher process is that, under error conditions in the launcher, we create a ProcessRuntime object on a background thread for the purposes of telemetry logging, but we also allow the main thread to proceed to start as the browser. This could result in a scenario where the main thread, as the browser process, is attempting to instantiate its ProcessRuntime and ends up racing with the launcher process's telemetry thread which has its own ProcessRuntime. To account for this situation, we add mutual exclusion to the process-wide initialization code. We host this part inside mozglue since that state is shared between both firefox.exe and xul.dll. * We clean up ProcessRuntime::InitializeSecurity by using Vector to set up the EXPLICIT_ACCESS entries. * We remove mscom::MainThreadClientInfo and replace it with a direct call to CoGetCallerTID * We revise all references to this class to use the new name. Differential Revision: https://phabricator.services.mozilla.com/D19551 --HG-- rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h extra : moz-landing-system : lando
2019-02-14 21:56:20 +03:00
mozilla::mscom::ProcessRuntime mCOMRuntime;
#endif
DISALLOW_EVIL_CONSTRUCTORS(ContentProcess);
};
} // namespace dom
} // namespace mozilla
#endif // ifndef dom_tabs_ContentThread_h