Live data from Hacker News

C stdlib isn't threadsafe and even safe Rust didn't save us

edgedb.com

291–300 of 370 posts

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#291
post #273

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 "—")

My policy about interacting with a person using a bot is actually the exact same as it is when interacting with someone who writes their own comments. This is actually very convenient because it completely eliminates any arguments about whether or not they are using an LLM or whether I have some sort of "bias" against them. My core argument is this: I treat the content coming out of it as being said by you. In this case the comments were of substandard quality. If the user was writing them by themselves, then the hope is that they will read my message and realize why and improve themselves in the future. If it was done by consulting something else, the idea is that they should reconsider the quality of its output. Either way, they're the one who comes out of it looking poorly.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#292
post #232

Earlier 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...

The problem (with get/set/putenv as they are) was isn't the non-use of a mutex. It's the "meaning" of the pointer returned to by getenv(). It returns a char*. Nevermind the persistance of that value - you can work around that by deliberately leaking memory - but it's writeable. Whether it's a good idea to do so ... well. But simply locking "inside" these funcs doesn't solve all the / your issues.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#293
env::set_var is marked unsafe now: https://doc.rust-lang.org/std/env/fn.set_var.html

And:

> 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

#294
post #5

The 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.

Is that the underlying problem, or is the underlying problem that libraries are using thread-unsafe setenv in threaded contexts when they could just do something else?

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#295
post #92

Earlier 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.

The current working directory is kernel state. getcwd() is a system call. This doesn't compare.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#296
post #276

Earlier 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.

The p in pthreads stands for Posix. I.e., uh, Posix is neither set in stone, nor entirely predates threads.

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?

> 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

#300
post #232

Earlier 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?

Imagine you get a signal during getenv itself with the mutex held. Then your signal handler calls getenv. (On the other hand -- getenv is not marked async-signal-safe, so this use is already illegal.)
Post reply on HN