Description
I've hit a few bugs in various crate test suites where 2 different tests both modify POSIX ENV, and then execute code and assertions based on those changes.
Often, this works simply due to the code being fast enough, but you can randomly get weird failures due to the data races in ENV, due to ENV being shared between threads.
But I don't see any documentation pointing out either:
a. That this risk occurs
b. How this risk occurs
c. How to manage this risk.
The best I see is: https://doc.rust-lang.org/nightly/std/env/fn.set_var.html
But its current prose of "Note that while concurrent access to environment variables is safe in Rust" can give the false impression that there isn't any problem to manage here unless one is doing FFI.
It needs to be more explicit, and highlight that you can trip into this when writing just plain ol' rust without anything fancy, with no external crates, and no custom ffi code.
( And probably needs to be mentioned at a higher level, like https://doc.rust-lang.org/nightly/std/env/index.html )
In tests, its especially spicy, as a test failing (which is ultimately a panic!), results in the Mutex becoming poisoned, which, if not managed properly in the tests, results in all tests that need to lock ENV, also failing with confusing errors, due to said poisoning.
There's already 2 PR's where I've submitted working solutions for this, and perhaps some of the strategies I've used could be used as a baseline for some documented guidance.
( Personally I wish rust wrapped the env access controls to protect code against this sort of problem, but asking for that is a bit of a tall order for me, so a documentation solution is better than nothing )