We're currently inserting an intermediate port into the peer address-space and then sending across that, so in principle we'd just replace this with simple insertion of the original port right, directly into the peer task.

We can insert into the peer process, but if the port name is already in-use there then we'll get a KERN_NAME_EXISTS failure. Conversely, we can allocate a new "dead" name and insert using that, but then mach_port_insert_rights() will fail with KERN_RIGHT_EXISTS if the receiving task already has a name for that port.

We can instead continue to use mach_msg(), takes care of whether to increment the ref-count of an existing port name, or allocate a new one, but then we to arrange a port across which to send. We could use a port per-Channel, in principle, but only if we can move the port-sending work into ChannelPosix, to keep it synchronized with Message sending.

Alternatively we can allocate an intermediate port per-Message, write all the ports-to-send into that, and pass the name in the MachPortsExtraHeader rather than a separate name per-port. This should still allow us to eliminate the MACH_NAME complexity.

> We can insert into the peer process, but if the port name is already in-use there then we'll get a KERN_NAME_EXISTS failure. 

This is what you want. You'll need to guess at random port names until you find a free space. This seems kind of weird [partly why I didn't do this when first implementing, but *shrug*.

> Alternatively we can allocate an intermediate port per-Message, write all the ports-to-send into that, and pass the name in the MachPortsExtraHeader rather than a separate name per-port. This should still allow us to eliminate the MACH_NAME complexity.

Err...I actually think this is more complex than the current solution.

> This is what you want. You'll need to guess at random port names until you find a free space. This seems kind of weird [partly why I didn't do this when first implementing, but *shrug*.

I think you should be able to allocate a dead name right into the target task space, and then insert a real right on top of that name.

Re #2: Agreed, I would prefer not to guess random port names; that seems
silly and fragile. As for complexity, it's similar to the current solution,
with the difference that we reduce the number of RPCs to the receiving task
from several-per-port to a couple per-message. It'd still be simpler for
most surrounding code because it would no longer have to deal with
MACH_NAME, only MACH or POSIX (though you might argue that a lot of the
complexity with the current impl is more a question of the different bits
of code being spread across a load of different layers, rather than the
mechanism itself).

Re #3: I don't think that will work, though; I think
mach_port_insert_rights() will only work in that way if the peer process
doesn't already have a name for the right we're sending - if it already has
that right, under a different name, then the call will fail with
KERN_RIGHT_EXISTS.

Ahh, I see. The automatic de-duplication of already-existing ports [to avoid KERN_RIGHT_EXISTS] is why we originally went with the intermediary port solution. I don't think there's a simpler solution than the current mechanism.

So based on comment #5 this sounds like a no-op.