0002788: Pass IPC pipe handle to child processes directly - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0002788	GNUnet	obsolete	public	2013-02-11 16:03	2024-05-03 13:51

Reporter	LRN	Assigned To	LRN
Priority	normal	Severity	feature	Reproducibility	N/A
Status	closed	Resolution	fixed
Product Version	Git master
Target Version	0.10.0	Fixed in Version	0.10.0

Summary	0002788: Pass IPC pipe handle to child processes directly
Description	Instead of sharing a named pipe name with the child, and allowing child to connect to it, which gives other processes a chance to beat the child process to that, we should just create both ends of the pipe in parent process, then make the read end inheritable, snprintf() its handle into child's environment at its creation, close our copy of the read end, and let the child read the handle value from environment and use it. Since handle values do not change when they are inherited, this will work, while other processes will not be able to use the handle (if they read child's envtable), since they did not inherit it.
Tags	No tags attached.

LRN 2013-02-12 14:31 reporter ~0006861	LRN: ok, this method, passing pipe as a handle, has one unforseen problem LRN: when it's used the child ALWAYS gets the pipe, whether it's our process, or something else (say, that w32cat i wrote, which is not pipe-controllable) LRN: if it's something else, the pipe just hangs inside the child LRN: we can write into our end, and the write will succeed, since the pipe is buffered LRN: so when we signal the child to die, the signalling call reports success LRN: then process_wait() with INFINITE is called, and we hang up forever, because the child (w32cat in my case) doesn't know it should die, and doesn't die LRN: possible fixes: 1) fix w32cat to be pipe-controllable LRN: obviously, other processes that are not pipe-controllable will also have to be fixed LRN: and if we can't change them (which is true for any external programs we run), we're screwed LRN: 2) Fix process_wait() to not to wait forever LRN: That would produce unexpected results for callers that use process_wait() to wait until the child dies, because now there will be a timeout instead LRN: Also, making it kill the process after timeout is not a good idea, since process_wait() is not supposed to kill anything LRN: 3) Fix _kill() function to wait until the child is dead, and if it isn't, it should force the issue LRN: that will produce unexpected delays for callers that use process_kill() without following up with process_wait() LRN: by the way, that is not W32-only problem, on *nix it should have the same result LRN: for now i see no way of fixing it gracefully without complicating the implementation (such as adding a _second_ pipe that runs in the opposite direction, and then having the child respond via it if the child is manageable, and otherwise assume it to be unmanageable, and kill it normally)

LRN 2013-03-04 06:45 reporter ~0006918	Eventually we decided to use a simple rule: if the caller asked to spawn a child process with a control pipe, then assume that child process does support controlling via the pipe. I.e. caller must know what the child process is, and whether it supports pipe controlling or not.

Date Modified	Username	Field	Change
2013-02-11 16:03	LRN	New Issue
2013-02-11 16:03	LRN	Status	new => assigned
2013-02-11 16:03	LRN	Assigned To	=> LRN
2013-02-12 14:31	LRN	Note Added: 0006861
2013-03-04 06:45	LRN	Note Added: 0006918
2013-03-04 06:45	LRN	Status	assigned => resolved
2013-03-04 06:45	LRN	Resolution	open => fixed
2013-03-18 14:57	Christian Grothoff	Product Version	=> Git master
2013-03-18 14:57	Christian Grothoff	Fixed in Version	=> 0.10.0
2013-03-18 14:57	Christian Grothoff	Target Version	=> 0.10.0
2013-12-24 20:55	Christian Grothoff	Status	resolved => closed
2024-01-12 14:28	schanzen	Category	Win32 port => Win32 port (deprecated)
2024-05-03 13:51	Christian Grothoff	Category	Win32 port (deprecated) => obsolete