Repository navigation
Expand the scope of std::process #941
Description
Like #939, this issue is intended to collect information about the expansion of the std::process module. As with most of the rest of the I/O reform, the goal of std::process was originally to be quite conservative. Over time we knew we were going to want to expand the module after we got experience using it as well as seeing how this sort of expansion plays out in the bigger picture.
I'll list some pieces below of parts I think that could be expanded, and I'll try to keep the list updated over time:
- The I/O handle types do not expose their internals. This means that on unix even though a pipe is known to be a file descriptor, the file descriptor is not accessible for interoperation with other I/O libraries.
- It is not possible to specify a custom I/O handle as one of the stdio descriptors. For example on unix the stdin could be specified as a specific file descriptor which already exists. This functionality needs to be fleshed out on Windows first. - std::process should provide a facility to specify custom file descriptors to stdin/stdout/stderr #893
- Process spawning should expose dropping capabilities on linux - Process spawning should expose the ability to drop capabilities on linux rust#12137
- File descriptors may be leaked when spawning processes - Danger of leaking file descriptors when spawning processes rust#12148
- Spawning a daemon process is not currently possible (on either windows or unix)
- A post-fork function to execute on unix would be useful for fine-tuning behavior for the child
- Waiting for a child with a timeout on windows is fairly trivial to implement but is not expose currently. (implemented in a separate repo)
As with #939 I don't plan on writing an RFC about this expansion in the near future, but I'd like one place to collect information about how std::process can be expanded.
Activity
std: Deprecate the old_io::process module
Rollup merge of rust-lang#23079 - alexcrichton:deprecate-process, r=a…
l0kod commentedon Mar 6, 2015
std::processshould provide a way to deliberately leak file descriptors/handles and get/use them back (i.e. oldCommand::extra_io, lost with rust-lang/rust#18557), not only stdio.alexcrichton commentedon Mar 6, 2015
Certainly, I consider that to fall under the "It is not possible to specify a custom I/O handle as one of the stdio descriptors" umbrella where we're not really leaking them per-se but you should be able to specify that an existing file descriptor should exist as another in the new process.
l0kod commentedon Mar 21, 2015
A post-fork function (cf. #579 (comment)) seems to need properties similar to
FnAsync(i.e. signal handler) to be safe.nagisa commentedon May 18, 2015
Need to add a way to wait for children with a timeout.
genodeftest commentedon May 29, 2015
I need a way to check whether a child process is still running or not.
l0kod commentedon Jun 20, 2015
Is there any plan to re-add
detached(&mut self)tostd::os::unix::process::CommandExt? Is there another way to do it without a manual unsafefork(2)handling?cc @aturon
Auto merge of #26470 - l0kod:process-session-leader, r=alexcrichton
pnathan commentedon Oct 11, 2015
Hi,
I think this is the relevant RFC, just let me know if it isn't and I'll remove my comment and file elsewhere.
About 1 year ago, I had a nice piece of code[0], which let me run a subprocess and provide streaming updates of its stdout/stderr descriptors. It is code which is intended for a long-running system: e.g., commands that run for hours and the controlling job needs to respond rather than block.
Right now, Process::Command & family do not appear to support this ability. I think with certain abuses of the borrow checker, I can kludge my way to part of this, but it's a lot of fiddly work when really, the original API supported what I need.
I'd like to see functionality in std::process explicitly for this case.
[0] https://gist.github.com/pnathan/30e283cbcf2bf4f46346#file-action-lib-rs-L134
BurntSushi commentedon Oct 12, 2015
@pnathan I only briefly scanned your code, but why exactly can't you just read from the
Childstdout/stderr descriptors?alexcrichton commentedon Oct 12, 2015
@pnathan I agree with @BurntSushi that what you did previously should definitely be possible with today's
std::process. I also updated the checklist above and basically all I/O-related tasks have since been implemented in one form or another.pnathan commentedon Oct 12, 2015
@alexcrichton @BurntSushi - hmm. Maybe I got into a corner with reading from the pipes, certainly has happened before. However, I still don't see any way in the API to check if a process is dead, only
wait. Am I misunderstanding something?sfackler commentedon Oct 12, 2015
We could pretty easily add a nonblocking version of wait but I don't think we do right now.
alexcrichton commentedon Oct 12, 2015
@pnathan yeah there's not currently a way to do that, but that's largely because it's quite tricky! On Unix unfortunately
killwith a 0 signal won't work reliably 100% of the time because there's no guarantee that the pid being verified hasn't been recycled. I think the best way to do this would bewaitwithWNOHANG, but that unfortunately needs builtin support that @sfackler mentioned.In the meantime though so long as you're careful with calling wait you can use this repo in the meantime which should allow you to wait with a timeout of 0.
l0kod commentedon Oct 12, 2015
On Linux, the PID is only recycled if the parent waits for the child exit code, otherwise it is transform into a zombie process.
In the future, CLONE_FD could land in the kernel, which would be much safer.
alexcrichton commentedon Oct 12, 2015
Ah right of course!
mllken commentedon Oct 25, 2015
Another one for the list above- It is not possible to specify a custom I/O handle as one of the NON-stdio descriptors (extra_io)
alexcrichton commentedon Nov 10, 2015
cc #1359, an RFC to add a few extra pieces of functionality on Unix
LukasKalbertodt commentedon Jan 31, 2016
What about process groups or child processes of some
Child? I don't know how this works with Windows, though. But I guess it should be somehow possible to get access to the process group of one spawned process.kamalmarhubi commentedon Feb 1, 2016
With Linux, it'd be good to expose the
PR_SET_CHILD_SUBREAPERprctlhere. This would make the parent process play the role ofinitfor any processes spawned by the child. Docs atprctl(2).alexcrichton commentedon Feb 11, 2016
With #1359 now implemented in rust-lang/rust#31409 (and tracked for stabilization by rust-lang/rust#31398) this issue should now basically be entirely possible using libstd itself.
The original motivation has basically now been fulfilled, so I'm going to close this. There are perhaps some more specific APIs which could be added or bound, but those likely want to have separate issues or start out as crates on crates.io.
kamalmarhubi commentedon Feb 11, 2016
👍