bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mach "pipe" between parent and child


From: Kalle Olavi Niemitalo
Subject: Re: Mach "pipe" between parent and child
Date: Wed, 26 Oct 2016 22:22:40 +0300
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.51 (gnu/linux)

"Brent W. Baccala" <cosine@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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]