Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

edgedb.com

Post reply on HN
Print view View original

21–30 of 370 posts

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

#21

Post by masklinn »

Thaxll wrote: post #13
ChrisSD wrote: post #4

In the Rust std, `set_var` and `remove_var` will correctly require using an `unsafe {}` block in the next edition (2024). The documentation does now mention the safety issue but obviously it was a mistake to make these functions safe originally (albeit a mistake even higher level languages have made). https://doc.rust-lang.org/stable/std/env/fn.set_var.html There is a patch for glibc which makes `getenv` safe in more…

Why requiring unsafe when the std implementation could take care of the synchronisation?

Because the std implementation can not force synchronisation on the libc, so any call into a C library which uses getenv will break... which is exactly what happened in TFA: `openssl-probe` called env::set_var on the Rust side, and the Python interpreter called getenv(3) directly.

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

#22

Post by [deleted] »

umpalumpaaa wrote: post #9
jandrese wrote: post #2

Yet another person is burned by calling setenv() in a multi-threaded context. There really needs to be a big warning banner on the manpage for setenv() that warns about this because it seems like a far more common problem than you would expect.

The man page says: > POSIX.1 does not require setenv() or unsetenv() to be reentrant. A non-reentrant function cannot be thread safe. In general (for POSIX, libc and many other libraries: if the docs do not explicitly say "this function is thread safe" they are not).

[deleted]

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

#23

Post by sim7c00 »

forrestthewoods wrote: post #3

Mutable global state is evil. Friends don’t let friends use mutable global state. I hate envvars. It’s “the Linux way”. I avoid them like the plague. A++ strong recommend. libc is terrible. The world needs to move on.

what do you suggest as alternative?

the problem is not linux, not mutable global state or resources and not libc.

the problem is not getting time at work to do things properly. like spotting this in GDB before the issue hit, because your boss gave you time to tirelessly debug and reverse your code and anything it touches....

there is too much money in halfbaked code. sad but true.

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

#25

Post by umpalumpaaa »

wmf wrote: post #14
umpalumpaaa wrote: post #9

Earlier quoted context omitted.

The man page says: > POSIX.1 does not require setenv() or unsetenv() to be reentrant. A non-reentrant function cannot be thread safe. In general (for POSIX, libc and many other libraries: if the docs do not explicitly say "this function is thread safe" they are not).

It's time to move beyond this attitude and make things safe by default. For example, Solaris has a safer version of setenv(). "It is ridiculous that this has been a known problem for so long. It has wasted thousands of hours of people's time, either debugging the problems, or debating what to do about it. We know how to fix the problem." https://www.evanjones.ca/setenv-is-not-thread-safe.html

I am not sure making things safe by default is a good idea. This always comes with a cost. Thats also the reason why basic data types (array, dictionaries, etc) are generally not thread safe… because its usually not needed or handled on a much higher level.

Its a different story for languages/environments that are supposed to be safe by default and where you have language features that ensure safety (actors, optionals etc) but not for something like libc which has a standard it has to conform to and like 100 years of history.

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

#26

Post by zanderwohl »

shikon7 wrote: post #24

I wonder why it is so hard for Rust to implement its own safe stdlib independent of C.

It would be a tremendous amount of work, and would take years. Meanwhile, the problems are avoidable. It's not exactly the "rust way" to just remember and avoid problems, but everything in language design is compromises.

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

#28

Post by do_not_redeem »

shikon7 wrote: post #24

I wonder why it is so hard for Rust to implement its own safe stdlib independent of C.

The crash in the article happened when Python called C's getenv. Rust could very well throw away libc, but then it would also be throwing away its great C interop story. Rust can't force Python to use its own stdlib instead of libc.

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

#29

Post by vlovich123 »

Even if C stdlib maintainers are resistant against making setenv multi-thread safe, at a minimum there should be a new alternative thread-safe API defined, whether within POSIX or defining a defacto standard and forcing POSIX to adopt it over time. If instead of explaining why nothing could be done was spent fixing this problem, a new thread-safe API could have replaced the old setenv which could have been deprecated and removed from many software projects.

I'm also not convinced by Musl's maintainer that it can't be fixed within Musl considering glibc is making changes to make this a non-issue.

Post reply on HN