gecko-dev/ipc/glue/SharedMemoryBasic_mach.h

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

111 строки
2.9 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
* 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 mozilla_ipc_SharedMemoryBasic_mach_h
#define mozilla_ipc_SharedMemoryBasic_mach_h
#include "base/file_descriptor_posix.h"
#include "base/process.h"
#include "SharedMemory.h"
#include <mach/port.h>
Bug 1265824 - Wait on texture handles with IPC r=jld,mattwoodrow There's a lot going on here, but it all fits under the idea of being able to communicate about texture locking statuses without spinning on IsReadLocked. This is a bit of a trade - we could just always allocate/grab a texture from the pool, which would put a smaller cap on the amount of time we can possibly spend when a texture is locked. However, this eats up more CPU and memory than waiting on the textures to unlock, and could take longer, especially if there were a large number of textures which we just need to wait for for a short amount of time. In any case, we very rarely hit the case where we actually need to wait on the sync IPC to the compositor - most of the time the textures are already unlocked. There is also an async IPC call in here, which we make before flushing async paints. This just causes the compositor to check whether the GPU is done with its textures or not and unlock them if it is. This helps us avoid the case where we take a long time painting asynchronously, turn IPC back on at the end of that, and then have to wait for the compositor to to get into TiledLayerBufferComposite::UseTiles before getting a response. Specifically this eliminates several talos regressions which use ASAP mode. Lastly, there seem to be no other cases of static Monitors being used. This seems like it falls under similar use cases as StaticMutexes, so I added it in. I can move it into its own file if we think it might be generally useful in the future. MozReview-Commit-ID: IYQLwUqMxg2 --HG-- extra : rebase_source : 4f05832f51dae6db98773dcad03cb008a80eca6c
2018-05-06 01:46:26 +03:00
#include "chrome/common/mach_ipc_mac.h"
#ifdef FUZZING
# include "SharedMemoryFuzzer.h"
#endif
//
// This is a low-level wrapper around platform shared memory. Don't
// use it directly; use Shmem allocated through IPDL interfaces.
//
class MachPortSender;
class ReceivePort;
namespace mozilla {
namespace ipc {
Bug 1265824 - Wait on texture handles with IPC r=jld,mattwoodrow There's a lot going on here, but it all fits under the idea of being able to communicate about texture locking statuses without spinning on IsReadLocked. This is a bit of a trade - we could just always allocate/grab a texture from the pool, which would put a smaller cap on the amount of time we can possibly spend when a texture is locked. However, this eats up more CPU and memory than waiting on the textures to unlock, and could take longer, especially if there were a large number of textures which we just need to wait for for a short amount of time. In any case, we very rarely hit the case where we actually need to wait on the sync IPC to the compositor - most of the time the textures are already unlocked. There is also an async IPC call in here, which we make before flushing async paints. This just causes the compositor to check whether the GPU is done with its textures or not and unlock them if it is. This helps us avoid the case where we take a long time painting asynchronously, turn IPC back on at the end of that, and then have to wait for the compositor to to get into TiledLayerBufferComposite::UseTiles before getting a response. Specifically this eliminates several talos regressions which use ASAP mode. Lastly, there seem to be no other cases of static Monitors being used. This seems like it falls under similar use cases as StaticMutexes, so I added it in. I can move it into its own file if we think it might be generally useful in the future. MozReview-Commit-ID: IYQLwUqMxg2 --HG-- extra : rebase_source : 4f05832f51dae6db98773dcad03cb008a80eca6c
2018-05-06 01:46:26 +03:00
enum {
kGetPortsMsg = 1,
kSharePortsMsg,
kWaitForTexturesMsg,
kUpdateTextureLocksMsg,
kReturnIdMsg,
kReturnWaitForTexturesMsg,
kReturnPortsMsg,
kShutdownMsg,
kCleanupMsg,
};
struct MemoryPorts {
MachPortSender* mSender;
ReceivePort* mReceiver;
MemoryPorts() = default;
MemoryPorts(MachPortSender* sender, ReceivePort* receiver)
: mSender(sender), mReceiver(receiver) {}
};
class SharedMemoryBasic final : public SharedMemoryCommon<mach_port_t> {
public:
static void SetupMachMemory(pid_t pid, ReceivePort* listen_port,
MachPortSender* listen_port_ack,
MachPortSender* send_port,
ReceivePort* send_port_ack, bool pidIsParent);
static void CleanupForPid(pid_t pid);
static void Shutdown();
Bug 1265824 - Wait on texture handles with IPC r=jld,mattwoodrow There's a lot going on here, but it all fits under the idea of being able to communicate about texture locking statuses without spinning on IsReadLocked. This is a bit of a trade - we could just always allocate/grab a texture from the pool, which would put a smaller cap on the amount of time we can possibly spend when a texture is locked. However, this eats up more CPU and memory than waiting on the textures to unlock, and could take longer, especially if there were a large number of textures which we just need to wait for for a short amount of time. In any case, we very rarely hit the case where we actually need to wait on the sync IPC to the compositor - most of the time the textures are already unlocked. There is also an async IPC call in here, which we make before flushing async paints. This just causes the compositor to check whether the GPU is done with its textures or not and unlock them if it is. This helps us avoid the case where we take a long time painting asynchronously, turn IPC back on at the end of that, and then have to wait for the compositor to to get into TiledLayerBufferComposite::UseTiles before getting a response. Specifically this eliminates several talos regressions which use ASAP mode. Lastly, there seem to be no other cases of static Monitors being used. This seems like it falls under similar use cases as StaticMutexes, so I added it in. I can move it into its own file if we think it might be generally useful in the future. MozReview-Commit-ID: IYQLwUqMxg2 --HG-- extra : rebase_source : 4f05832f51dae6db98773dcad03cb008a80eca6c
2018-05-06 01:46:26 +03:00
static bool SendMachMessage(pid_t pid, MachSendMessage& message,
MachReceiveMessage* response);
SharedMemoryBasic();
virtual bool SetHandle(const Handle& aHandle, OpenRights aRights) override;
virtual bool Create(size_t aNbytes) override;
virtual bool Map(size_t nBytes, void* fixed_address = nullptr) override;
virtual void CloseHandle() override;
virtual void* memory() const override {
#ifdef FUZZING
return SharedMemoryFuzzer::MutateSharedMemory(mMemory, mAllocSize);
#else
return mMemory;
#endif
}
virtual SharedMemoryType Type() const override { return TYPE_BASIC; }
static Handle NULLHandle() { return Handle(); }
static void* FindFreeAddressSpace(size_t aSize);
virtual bool IsHandleValid(const Handle& aHandle) const override;
virtual bool ShareToProcess(base::ProcessId aProcessId,
Handle* aNewHandle) override;
private:
~SharedMemoryBasic();
void Unmap();
mach_port_t mPort;
// Pointer to mapped region, null if unmapped.
void* mMemory;
// Access rights to map an existing region with.
OpenRights mOpenRights;
};
} // namespace ipc
} // namespace mozilla
#endif // ifndef mozilla_ipc_SharedMemoryBasic_mach_h