Earlier quoted context omitted.
I am going to do this once, but not again. Please pay attention to it. You are not just wrong, but failing to demonstrate an understanding of the actual topic being discussed. I can't say whether you actually have it or not, but your responses do not demonstrate this. I have dealt with plenty of people on this site who say things that are factually incorrect, many of whom have argued with me when I do so. You are not…
Sounds like you are arguing with a bot? em-dashes are a giveaway (nobody sane uses these "—")
C stdlib isn't threadsafe and even safe Rust didn't save us
291–300 of 370 posts
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#292Earlier quoted context omitted.
But that won't actually fix the underlying problem, namely that getenv and setenv (or unsetenv, probably) cannot safely be called from different threads. It seems like the only reliable way to fix this is to change these functions so that they exclusively acquire a mutex.
> It seems like the only reliable way to fix this is to change these functions so that they exclusively acquire a mutex. A mutex can ensure thread safety but risks deadlocks if not used carefully and will hurt performance...
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#293And:
> This function is safe to call in a single-threaded program.
> This function is also always safe to call on Windows, in single-threaded and multi-threaded programs.
> In multi-threaded programs on other operating systems, the only safe option is to not use set_var or remove_var at all.
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#294The major takeaway from this is that Rust will be making environment setters unsafe in the next edition. With luck, this will filter down into crates that trigger these crashes ( https://github.com/alexcrichton/openssl-probe/issues/30 filed upstream in the meantime).
But that won't actually fix the underlying problem, namely that getenv and setenv (or unsetenv, probably) cannot safely be called from different threads. It seems like the only reliable way to fix this is to change these functions so that they exclusively acquire a mutex.
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#295Earlier quoted context omitted.
The underlying problem is that setenv is mutable global state and should never have existed
The process's current directory is mutable global state as well, and yet chdir(2) is thread-safe.
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#296Earlier quoted context omitted.
setenv and getenv have never been thread safe, why the concern with it now?
The concern now is that, unlike when Posix was set in stone, threads exist.
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#297I wonder why it is so hard for Rust to implement its own safe stdlib independent of C.
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#298> Our nightly CI machines run on Amazon AWS, which has the advantage of giving us a real, uncontainerized root user. > We don’t have the necessary files outside of the container, and our containers are quite minimal and don’t allow us to easily install gdb. Have people lost the ability to build and debug their code locally, without clouds and containers?
No, of course not, but it didn't crash on our machines!
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#299TIL that my set_env("RUST_LOG"...) calls at startup are technically unsafe. Funny. I should see if the env_logger crate has a better solution.
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#300Earlier quoted context omitted.
> It seems like the only reliable way to fix this is to change these functions so that they exclusively acquire a mutex. A mutex can ensure thread safety but risks deadlocks if not used carefully and will hurt performance...
Agree about performance, but wouldn't there need to be >1 mutex to risk a deadlock?