View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002788 | GNUnet | obsolete | public | 2013-02-11 15:03 | 2024-05-03 11:51 |
| Reporter | LRN | Assigned To | LRN | Due Date | |
| 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: 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) | |
| 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 15:03 | LRN | New Issue | |
| 2013-02-11 15:03 | LRN | Status | new => assigned |
| 2013-02-11 15:03 | LRN | Assigned To | => LRN |
| 2013-02-12 13:31 | LRN | Note Added: 0006861 | |
| 2013-03-04 05:45 | LRN | Note Added: 0006918 | |
| 2013-03-04 05:45 | LRN | Status | assigned => resolved |
| 2013-03-04 05:45 | LRN | Resolution | open => fixed |
| 2013-03-18 13:57 | Christian Grothoff | Product Version | => Git master |
| 2013-03-18 13:57 | Christian Grothoff | Fixed in Version | => 0.10.0 |
| 2013-03-18 13:57 | Christian Grothoff | Target Version | => 0.10.0 |
| 2013-12-24 19:55 | Christian Grothoff | Status | resolved => closed |
| 2024-01-12 13:28 | schanzen | Category | Win32 port => Win32 port (deprecated) |
| 2024-05-03 11:51 | Christian Grothoff | Category | Win32 port (deprecated) => obsolete |