In 2015, another consideration was given to using Mach IPC, and the results of that survey are here.

Rationale for not using Mach based IPC:
Chrome handles network communication and IPC messages on the same thread.  Sockets are waited on using kqueues via libevent.
Although there is a constant defined in the kqueue headers on OS X (EVFILTER_MACH in sys/event.h), there is currently no way to block on both a socket and a mach port at once, this means that our only option is to spawn another thread to bridge Mach messages to kqueue.  Our reference implementation does this by opening a pipe between both threads and writing a byte each time a Mach message is received.

Because of this extra step, we now need to pay the price both of receiving a Mach message and communicating via a pipe between threads.  We've timed this approach and found it to be 10uSec slower on Desktops & 20uSecs faster on laptops than a pure pipe based implementation.

If you look at the measurements at the bottom of this document, you can see that most of the messages Chrome sends are very small.  So the performance benefits of Mach messages over pipes are negligible.

Thus our decision at this time is to use the same approach as Linux.  If we run into problems at a later date with a pipe-based implementation we can revert to the Mach-based one.

Mach based IPC:

Summary of departures from current Windows architecture:
PC::Channel: This class basically needs to be rewritten to use Mach ports, we require a bidirectional communication mechanism able to transfer arbitrarily sized messages.  This means we need to create two Mach ports (Server->Client & Client->Server).
Establishing Communications: (From chrome/common/ipc_channel.h)

enum Mode {

    MODE_SERVER,

    MODE_CLIENT

  };

IPC::Channel::Channel(const std::wstring& channel_id, Mode mode, Listener* listener);

bool Connect();

When a Channel is created in Server mode it creates a Mach port and registers it with the Bootstrap server using the channel_id prefixed with the string 'chrome_'.  It then sets waiting_connect_ to false.
When a Channel is opened in Client mode, the Channel ID is looked up on the Bootstrap server.  The client then creates a Mach port for incoming messages, it sends a Hello message to the server containing port rights to its incoming port and the authorization token sent over the pipe. Upon receiving a Hello message, the Server verifies the token, if it's valid, it stores the send port rights and sets waiting_connect_ to false.
Server->Client. Sending Messages: (From chrome/common/ipc_channel.h)

 bool Send(Message* message);

Mach ports have a fixed queue size, we want to be able to send arbitrary numbers of messages without blocking. Messages to send over the wire are queued up on the Server side in an std::vector<Message*>, we specify a timeout value when sending a Mach message, if the send times out then we set a delayed task to attempt to resend the message after a delta. When IPC::Channel::Send() is called, we attempt to send out all the messages in our outgoing queue until we block.
Receiving messages: Messages can be an size up to 256MB, this presents a problems since we don't want to allocate a 256MB buffer to receive messages into. We can allocate an input buffer of a reasonable size, and specify the MACH_RCV_LARGE flag when receiving messages, if the message doesn't fit into our buffer then we get a chance to dynamically allocate a new receive buffer and stick our data in there. We will probably also want to look at large messages and send those over as OOL transfer (OS X Internals 9.5.5) so that they're transferred with copy-on-write semantics.
Security:
The initial security token provides security in the face of rogue client processes trying to connect back to a server, we can use the OS X Authorization Services API & AuthorizationMakeExternalForm() to generate the token.
We can make use of Mach's sender security token (OS X Internals 9.2.2.3) to prevent processes not owned by the user from communicating with the server.

Current Windows implementation: