From 0076a3b037df15824302d2d921b580f99899c86a Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Wed, 27 Jan 2021 17:32:04 +0000 Subject: [PATCH] std::process:Child: discuss other problems with just dropping See #70186 which makes the point about io handles. Signed-off-by: Ian Jackson --- library/std/src/process.rs | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/library/std/src/process.rs b/library/std/src/process.rs index 3b7d808a5b96b..c9569abc622f4 100644 --- a/library/std/src/process.rs +++ b/library/std/src/process.rs @@ -132,15 +132,25 @@ use crate::sys_common::{AsInner, AsInnerMut, FromInner, IntoInner}; /// /// # Warning /// +/// A `Child` which is simply dropped may continue running in parallel, +/// possibly even after the program which launched it exits. +/// If it inherited stdin/stdout, it may still read and write to them +/// later, causing confusion and disruption. +/// /// On some systems, calling [`wait`] or similar is necessary for the OS to /// release resources. A process that terminated but has not been waited on is /// still around as a "zombie". Leaving too many zombies around may exhaust /// global resources (for example process IDs). /// +/// Unless [`wait`] is called, any failure of the child will not be +/// visible. +/// /// The standard library does *not* automatically wait on child processes (not /// even if the `Child` is dropped), it is up to the application developer to do -/// so. As a consequence, dropping `Child` handles without waiting on them first -/// is not recommended in long-running applications. +/// so. +/// +/// For these reasons, dropping `Child` handles without waiting on them first +/// is usually incorrect. /// /// # Examples ///