From 27685d9b26e60da2b8b8a56b1847d805e64bd821 Mon Sep 17 00:00:00 2001 From: Tobias Bucher Date: Mon, 3 Jun 2024 20:09:49 +0200 Subject: [PATCH] Remove lock guarantee from `std::env::{set_var, remove_var}` CC #124866. CC https://github.com/rust-lang/rust/pull/124636#discussion_r1613386094. --- library/std/src/env.rs | 42 ++++++++++++++++++++---------------------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/library/std/src/env.rs b/library/std/src/env.rs index 4d649f8a6f136..63a12378df6bd 100644 --- a/library/std/src/env.rs +++ b/library/std/src/env.rs @@ -326,17 +326,16 @@ impl Error for VarError { /// In multi-threaded programs on other operating systems, we strongly suggest /// not using `set_var` or `remove_var` at all. The exact requirement is: you /// must ensure that there are no other threads concurrently writing or -/// *reading*(!) the environment through functions or global variables other -/// than the ones in this module. The problem is that these operating systems -/// do not provide a thread-safe way to read the environment, and most C -/// libraries, including libc itself, do not advertise which functions read -/// from the environment. Even functions from the Rust standard library may -/// read the environment without going through this module, e.g. for DNS -/// lookups from [`std::net::ToSocketAddrs`]. No stable guarantee is made about -/// which functions may read from the environment in future versions of a -/// library. All this makes it not practically possible for you to guarantee -/// that no other thread will read the environment, so the only safe option is -/// to not use `set_var` or `remove_var` in multi-threaded programs at all. +/// *reading*(!) the environment through functions or global variables. The +/// problem is that these operating systems do not provide a thread-safe way to +/// read the environment, and most C libraries, including libc itself, do not +/// advertise which functions read from the environment. Even some functions +/// from the Rust standard library read the environment, e.g. for DNS lookups +/// from [`std::net::ToSocketAddrs`]. No stable guarantee is made about which +/// functions may read from the environment in future versions of a library. +/// All this makes it not practically possible for you to guarantee that no +/// other thread will read the environment, so the only safe option is to not +/// use `set_var` or `remove_var` in multi-threaded programs at all. /// /// Discussion of this unsafety on Unix may be found in: /// @@ -393,17 +392,16 @@ unsafe fn _set_var(key: &OsStr, value: &OsStr) { /// In multi-threaded programs on other operating systems, we strongly suggest /// not using `set_var` or `remove_var` at all. The exact requirement is: you /// must ensure that there are no other threads concurrently writing or -/// *reading*(!) the environment through functions or global variables other -/// than the ones in this module. The problem is that these operating systems -/// do not provide a thread-safe way to read the environment, and most C -/// libraries, including libc itself, do not advertise which functions read -/// from the environment. Even functions from the Rust standard library may -/// read the environment without going through this module, e.g. for DNS -/// lookups from [`std::net::ToSocketAddrs`]. No stable guarantee is made about -/// which functions may read from the environment in future versions of a -/// library. All this makes it not practically possible for you to guarantee -/// that no other thread will read the environment, so the only safe option is -/// to not use `set_var` or `remove_var` in multi-threaded programs at all. +/// *reading*(!) the environment through functions or global variables. The +/// problem is that these operating systems do not provide a thread-safe way to +/// read the environment, and most C libraries, including libc itself, do not +/// advertise which functions read from the environment. Even some functions +/// from the Rust standard library read the environment, e.g. for DNS lookups +/// from [`std::net::ToSocketAddrs`]. No stable guarantee is made about which +/// functions may read from the environment in future versions of a library. +/// All this makes it not practically possible for you to guarantee that no +/// other thread will read the environment, so the only safe option is to not +/// use `set_var` or `remove_var` in multi-threaded programs at all. /// /// Discussion of this unsafety on Unix may be found in: ///