- * This is the tough case to make atomic.
- * The difficult problem is serializing with port death.
- * At the time we copyin dest_port, it must be alive.
- * If reply_port is alive when we copyin it, then
- * we are OK, because we serialize before the death
- * of both ports. Assume reply_port is dead at copyin.
- * Then if dest_port dies/died after reply_port died,
- * we are OK, because we serialize between the death
- * of the two ports. So the bad case is when dest_port
- * dies after its copyin, reply_port dies before its
- * copyin, and dest_port dies before reply_port. Then
- * the copyins operated as if dest_port was alive
- * and reply_port was dead, which shouldn't have happened
- * because they died in the other order.
- *
- * Note that it is easy for a user task to tell if
- * a copyin happened before or after a port died.
- * For example, suppose both dest and reply are
- * send-once rights (types are both move-sonce) and
- * both rights have dead-name requests registered.
- * If a port dies before copyin, a dead-name notification
- * is generated and the dead name's urefs are incremented,
- * and if the copyin happens first, a port-deleted
- * notification is generated.
- *
- * Note that although the entries are different,
- * dest_port and reply_port might still be the same.
- *
- * JMM - The code to handle this was too expensive and, anyway,
- * we intend to separate the dest lookup from the reply copyin
- * by a wide margin, so the user will have to learn to deal!
- * I will be making the change soon in rdar://problem/6275821.