Pre-RFC: deprecate env::set_var

Yeah that’s what I was thinking, I suspect we’ll have a global StaticRwLock on Unix and we just hand out wrapped up RwLockReadGuard<'static, ()> and RwLockWriteGuard<'static, ()> (may as well provide both). I believe they’re inherently non-Send by default because unlocking from a different thread is undefined behavior.

And yeah, on Windows I would expect the struct returned to have the same non-Send property but otherwise just be a noop (e.g. a blank struct).

With this any API which calls into C which reads the environment would grab the read lock and if it may write to the environment it grabs the write lock. I think that you could also coordinate C -> Rust with this API where you call into Rust to ensure that no Rust code is working in the wrong way with the environment if C otherwise needs to touch it.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.