New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 791212 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 753541
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Mojo EDK: Refactor MACH vs MACH_NAME handling

Project Member Reported by w...@chromium.org, Dec 2 2017

Issue description

When Mojo messages containing Mach ports are send via IPC, for each sent-port an intermediate port is created in the target task and a send-once right extracted, through which the sent-port is passed.

PlatformHandle has MACH and MACH_NAME types used to distinguish the "intermediate" port from the port being transferred, though there are actually three different states that the PlatformHandle may be in:

1. It is of type MACH, and holds the port the application wishes to
   send/receive.
2. It is a MACH_NAME at the sender, and holds the name if the intermediate port
   in the recipient's address-space.
3. It is a MACH_NAME at the receive, and holds the receive right for the 
   intermediate port, from which to read the application port.

Ideally we should remove the need for MACH_NAME by making it an internal implementation detail of the mojo::edk::ChannelPosix under Mac OS. However, the MachPortRelay, which helps with associating peer process identifiers with Mach task ports, through which to pass handles, is not necessarily accessible to the Channel implementation.

 

Comment 1 by w...@chromium.org, May 30 2018

Mergedinto: 753541
Status: Duplicate (was: Assigned)
De-duping into the general ScopedPlatfornHandle/PlatformHandle cleanup bug.

Sign in to add a comment