"Brent W. Baccala" <cos...@freesoft.org> writes: > What is the best way to fork() a child and have a Mach receive right on the > parent connected to a send right on the child? Or vice versa?
I don't know whether it's the best way, but I did this in reply-leak.tar.gz posted to https://savannah.gnu.org/bugs/?48456 : 1. In the parent task, allocate a receive right and store the port name in a variable. 2. In the parent task, call fork. That creates the child task and gives it a receive right that has the same port name as in step 1, but refers to a different port. 3. In the parent task, start receiving messages. 4. In the child task, deallocate the unused receive right that was made by fork in step 2. (I suppose this step is optional.) 5. In the child task, use getppid and pid2task to get the task port of the parent task. (I don't know whether the parent task could instead call mach_task_self before forking, and save the port name in a variable that the child would inherit. There is a risk that fork might do something strange to the send right.) 6. In the child task, use mach_port_extract_right with MACH_MSG_TYPE_MAKE_SEND to get a send right that refers to the port that was created in step 1. Alternatively, one could perhaps use mach_ports_register and mach_ports_lookup. GNU Mach documentation says these are "not used in the Hurd", so I think the Hurd and the GNU C Library will not interfere if an application uses them. The parent task would create a receive right and register a corresponding send right. The child task would then look up the send right and use that to send messages to the parent task. I guess each scheme would be tricky to use in a multithreaded process without leaking ports.
