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.