# Synchronized FFI access to POSIX environment variable functions

**URL:** https://internals.rust-lang.org/t/synchronized-ffi-access-to-posix-environment-variable-functions/15475
**Category:** Unsafe Code Guidelines
**Created:** [October 21, 2021, 2:35pm UTC](https://internals.rust-lang.org/t/synchronized-ffi-access-to-posix-environment-variable-functions/15475 "2021-10-21T14:35:49Z")
**Posts on this page:** 1
**Showing post:** 88

<div class="post-metadata">

### Author: ![kpreid](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kpreid/32/8484_2.png) [@kpreid](https://internals.rust-lang.org/u/kpreid)
#### Post date: [November 2, 2021, 2:58pm UTC](https://internals.rust-lang.org/t/synchronized-ffi-access-to-posix-environment-variable-functions/15475/88 "2021-11-02T14:58:41Z")

</div>

There are a number of “systems programming” things which are safe (or at least better-behaved) iff there are no other threads, such as setting the environment as discussed here, `fork()`, some uses of signals, use of `!Sync` mutable globals, and probably lots of other things I'm not thinking of.

Therefore, I'm wondering if it would be useful to add to the Rust standard library a mechanism which allows safely invoking some of these things _given the `unsafe` creation of an explicit promise that the process is currently single-threaded,_ that would be passed as a parameter to the future version of `set_var` and such. The advantage of this over marking individual calls `unsafe` is that “not multithreaded” is a global property of the process related to the big picture of the program's control flow, so associating the “here is a property you can't necessarily statically guarantee that I promise is true” with some single high-level scope is more accurate and (slightly) more auditable than sprinkling it about every call site — and that it documents _what kind of unsafety_ is present.

Also, such a mechanism could be used fully safely on targets which inherently have no thread support. (This is not the same as “why not make this construct/function safe if we're on a single-threaded target”, which I've heard rejected before, because it would affect only the site where the promise is created, which is supposed to be rare, not every “leaf” that uses it.)

Disadvantage: this one-size-fits-all mechanism would not address the case mentioned above of threads which exist but aren't doing anything yet (which would be safe for environment manipulation but not for `fork()`, for example).

---

_[View the full topic](https://internals.rust-lang.org/t/synchronized-ffi-access-to-posix-environment-variable-functions/15475)._