about summary refs log tree commit diff
path: root/library/std/src/process.rs
AgeCommit message (Collapse)AuthorLines
2021-10-09Rollup merge of #88436 - lf-:stabilize-command-access, r=yaahcGuillaume Gomez-12/+8
std: Stabilize command_access Tracking issue: #44434 (not yet closed but the FCP is done so that should be soon).
2021-10-05Apply suggestions from code reviewJane Lusby-8/+8
2021-09-16Merge sys_common::rt into rtbjorn3-1/+1
2021-08-28std: Stabilize command_accessJade-12/+8
Tracking issue: #44434
2021-08-19Add comments about impls for File, TcpStream, ChildStdin, etc.Dan Gohman-0/+18
2021-08-06Auto merge of #87774 - camelid:process-typo, r=jyn514bors-1/+1
Fix typo Add missing "by".
2021-08-04Fix typoNoah Lev-1/+1
2021-08-04Re-use std::sealed::Sealed in os/linux/process.Mara Bos-0/+4
2021-07-21Add Linux-specific pidfd process extensionsAaron Hill-1/+1
Background: Over the last year, pidfd support was added to the Linux kernel. This allows interacting with other processes. In particular, this allows waiting on a child process with a timeout in a race-free way, bypassing all of the awful signal-handler tricks that are usually required. Pidfds can be obtained for a child process (as well as any other process) via the `pidfd_open` syscall. Unfortunately, this requires several conditions to hold in order to be race-free (i.e. the pid is not reused). Per `man pidfd_open`: ``` · the disposition of SIGCHLD has not been explicitly set to SIG_IGN (see sigaction(2)); · the SA_NOCLDWAIT flag was not specified while establishing a han‐ dler for SIGCHLD or while setting the disposition of that signal to SIG_DFL (see sigaction(2)); and · the zombie process was not reaped elsewhere in the program (e.g., either by an asynchronously executed signal handler or by wait(2) or similar in another thread). If any of these conditions does not hold, then the child process (along with a PID file descriptor that refers to it) should instead be created using clone(2) with the CLONE_PIDFD flag. ``` Sadly, these conditions are impossible to guarantee once any libraries are used. For example, C code runnng in a different thread could call `wait()`, which is impossible to detect from Rust code trying to open a pidfd. While pid reuse issues should (hopefully) be rare in practice, we can do better. By passing the `CLONE_PIDFD` flag to `clone()` or `clone3()`, we can obtain a pidfd for the child process in a guaranteed race-free manner. This PR: This PR adds Linux-specific process extension methods to allow obtaining pidfds for processes spawned via the standard `Command` API. Other than being made available to user code, the standard library does not make use of these pidfds in any way. In particular, the implementation of `Child::wait` is completely unchanged. Two Linux-specific helper methods are added: `CommandExt::create_pidfd` and `ChildExt::pidfd`. These methods are intended to serve as a building block for libraries to build higher-level abstractions - in particular, waiting on a process with a timeout. I've included a basic test, which verifies that pidfds are created iff the `create_pidfd` method is used. This test is somewhat special - it should always succeed on systems with the `clone3` system call available, and always fail on systems without `clone3` available. I'm not sure how to best ensure this programatically. This PR relies on the newer `clone3` system call to pass the `CLONE_FD`, rather than the older `clone` system call. `clone3` was added to Linux in the same release as pidfds, so this shouldn't unnecessarily limit the kernel versions that this code supports. Unresolved questions: * What should the name of the feature gate be for these newly added methods? * Should the `pidfd` method distinguish between an error occurring and `create_pidfd` not being called?
2021-07-05s/die/terminate/ in abort documentation.Mara Bos-1/+1
2021-07-05abort docs: Document buffer non-flushingIan Jackson-0/+3
There is discussion of this in #40230 which requests clarification. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-05aborts: Clarify documentation and commentsIan Jackson-0/+4
In the docs for intrinsics::abort(): * Strengthen the recommendation by to use process::abort instead. * Document the fact that it (ab)uses an LLVM debug trap and what the likely consequences are. * State that the precise behaviour is unstable. In the docs for process::abort(): * Promise that we have the same behaviour as C `abort()`. * Document the likely consequences, including, specifically, the consequences on Unix. In the internal comment for unix::abort_internal: * Refer to the public docs for the public API functions. * Correct and expand the description of libc::abort. Specifically: * Do not claim that abort() unregisters signal handlers. It doesn't; it honours the SIGABRT handler. * Discuss, extensively, the issue with abort() flushing stdio buffers. * Describe the glibc behaviour in some detail. Co-authored-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-03Rollup merge of #86803 - ↵Yuki Okushi-2/+2
xfix:remove-unnecessary-ampersand-from-command-args-calls, r=joshtriplett Remove & from Command::args calls in documentation Now that arrays implement `IntoIterator`, using `&` is no longer necessary. This makes examples easier to understand.
2021-07-02Remove & from Command::args calls in documentationKonrad Borowski-2/+2
Now that arrays implement `IntoIterator`, using `&` is no longer necessary. This makes examples easier to understand.
2021-07-02Auto merge of #85746 - m-ou-se:io-error-other, r=joshtriplettbors-3/+1
Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only*, and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change, since the user couldn't match on these errors anyway. This way, we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`
2021-06-25Fix a few misspellings.Eric Huss-1/+1
2021-06-15Redefine `ErrorKind::Other` and stop using it in std.Mara Bos-3/+1
2021-05-12impl crate::error::Error for ExitStatusErrorIan Jackson-0/+3
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-12ExitStatusError: Be more verbose in Display implIan Jackson-1/+1
Co-authored-by: Jane Lusby <jlusby@yaah.dev>
2021-05-12Fix typo in docIan Jackson-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-05-12unix: impl ExitStatusExt for ExitStatusErrorIan Jackson-3/+6
It is unergnomic to have to say things like bad.into_status().signal() Implementing `ExitStatusExt` for `ExitStatusError` fixes this. Unfortunately it does mean making a previously-infallible method capable of panicing, although of course the existing impl remains infallible. The alternative would be a whole new `ExitStatusErrorExt` trait. `<ExitStatus as ExitStatusExt>::into_raw()` is not particularly ergonomic to call because of the often-required type annotation. See for example the code in the test case in library/std/src/sys/unix/process/process_unix/tests.rs Perhaps we should provide equivalent free functions for `ExitStatus` and `ExitStatusExt` in std::os::unix::process and maybe deprecate this trait method. But I think that is for the future. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-12Provide ExitStatusErrorIan Jackson-3/+135
Closes #73125 This is in pursuance of Issue #73127 Consider adding #[must_use] to std::process::ExitStatus In MR #81452 Add #[must_use] to [...] process::ExitStatus we concluded that the existing arrangements in are too awkward so adding that #[must_use] is blocked on improving the ergonomics. I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741 Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-04-22Rework `at_exit` to `cleanup`Christiaan Dirkx-1/+1
2021-04-21Replace all `fmt.pad` with `debug_struct`Christiaan Dirkx-4/+4
2021-03-27Use DebugStruct::finish_non_exhaustive() in std.Mara Bos-1/+1
2021-03-14Rollup merge of #82943 - kornelski:threadstdio, r=joshtriplettYuki Okushi-7/+18
Demonstrate best practice for feeding stdin of a child processes Documentation change. It's possible to create a deadlock with stdin/stdout I/O on a single thread: * the child process may fill its stdout buffer, and have to wait for the parent process to read it, * but the parent process may be waiting until its stdin write finishes before reading the stdout. Therefore, the parent process should use separate threads for writing and reading. These examples are not deadlocking in practice, because they use short strings, but I think it's better to demonstrate code that works even for long writes. The problem is non-obvious and tricky to debug (it seems that even libstd has a similar issue: #45572). This also demonstrates how to use stdio with threads: it's not obvious that `.take()` can be used to avoid fighting with the borrow checker. I've checked that the modified examples run fine.
2021-03-09Demonstrate best practice for feeding stdin of a child processesKornel-7/+18
It's possible to create a deadlock with stdin/stdout I/O on a single thread: * the child process may fill its stdout buffer, and have to wait for the parent process to read it, * but the parent process may be waiting until its stdin write finishes before reading the stdout. Therefore, the parent process should use separate threads for writing and reading.
2021-02-23ExitStatus: Improve documentation re wait status vs exit statusIan Jackson-7/+18
The use of `ExitStatus` as the Rust type name for a Unix *wait status*, not an *exit status*, is very confusing, but sadly probably too late to change. This area is confusing enough in Unix already (and many programmers are already confuxed). We can at least document it. I chose *not* to mention the way shells like to exit with signal numbers, thus turning signal numbers into exit statuses. This is only relevant for Rust programs using `std::process` if they run shells. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-02-10Seal the CommandExt, OsStrExt and OsStringExt traitsAmanieu d'Antras-0/+8
2020-11-23Auto merge of #78439 - lzutao:rm-clouldabi, r=Mark-Simulacrumbors-1/+1
Drop support for all cloudabi targets `cloudabi` is a tier-3 target, and [it is no longer being maintained upstream][no]. This PR drops supports for cloudabi targets. Those targets are: * aarch64-unknown-cloudabi * armv7-unknown-cloudabi * i686-unknown-cloudabi * x86_64-unknown-cloudabi Since this drops supports for a target, I'd like somebody to tag `relnotes` label to this PR. Some other issues: * The tidy exception for `cloudabi` crate is still remained because * `parking_lot v0.9.0` and `parking_lot v0.10.2` depends on `cloudabi v0.0.3`. * `parking_lot v0.11.0` depends on `cloudabi v0.1.0`. [no]: https://github.com/NuxiNL/cloudabi#note-this-project-is-unmaintained
2020-11-22Drop support for cloudabi targetsLzu Tao-1/+1
2020-11-18Add #[cold] to `abort` and `handle_alloc_error`Benoît du Garreau-0/+1
2020-10-31Apply suggestions from code reviewMatyáš Racek-4/+8
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2020-10-31Add note to process::arg[s] that args shouldn't be escaped or quotedMatyáš Racek-0/+6
2020-10-18Add missing punctuationpierwill-1/+1
2020-09-26Add accessors to Command.Eric Huss-0/+125
2020-09-21Rollup merge of #76275 - FedericoPonzi:immutable-write-impl-73836, r=dtolnayecstatic-morse-0/+19
Implementation of Write for some immutable ref structs Fixes #73836
2020-09-21Update library/std/src/process.rsFederico Ponzi-1/+1
Co-authored-by: David Tolnay <dtolnay@gmail.com>
2020-09-16Rollup merge of #73955 - hellow554:unsafe_process, r=Mark-SimulacrumDylan DPC-2/+5
deny(unsafe_op_in_unsafe_fn) in libstd/process.rs The libstd/process.rs part of #73904 . Wraps the two calls to an unsafe fn Initializer::nop() in an unsafe block. Will have to wait for #73909 to be merged, because of the feature in the libstd/lib.rs
2020-09-11Deduplicates io::Write implementationsFederico Ponzi-4/+4
2020-09-03More implementations of Write for immutable refsFederico Ponzi-0/+19
Fixes #73836
2020-08-31std: move "mod tests/benches" to separate filesLzu Tao-408/+3
Also doing fmt inplace as requested.
2020-08-23doc: Fix typo in std::process::Child documentationJR Heard-1/+1
2020-08-14Rollup merge of #75432 - camelid:intra-doc-links-for-std-process, r=jyn514Tyler Mandry-58/+37
Switch to intra-doc links in `std::process` Part of #75080.
2020-08-14Improve documentation on process::Child.std* fieldsJonas Berlin-3/+24
As a relative beginner, it took a while for me to figure out I could just steal the references to avoid partially moving the child and thus retain ability to call functions on it (and store it in structs etc).
2020-08-11Use `Child::std{in,out,err}` instead of `Child.`Camelid-3/+3
These links were broken before.
2020-08-11Switch to intra-doc links in `std::process`Camelid-58/+37
2020-08-11deny(unsafe_op_in_unsafe_fn) in libstd/process.rsMarcel Hellwig-2/+5
2020-07-27mv std libs to library/mark-0/+2112
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 12:14:30 +0000