C stdlib isn't threadsafe and even safe Rust didn't save us • Hacker News Board

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

#281

Post by HarHarVeryFunny » Thu, Jan 23, 2025, 4:15 PM UTC

4gotunameagain wrote: post #181

HarHarVeryFunny wrote: post #125

What is the rationale for libc not making setenv/getenv thread safe? It does seem rather odd given how environment variables are explicitly defined as shared between threads in the same process! It doesn't seem it would take much to do it efficiently, even retaining the poor getenv() pointer-returning API (which could point to a thread local buffer). The coordination between getenv and setenv could be very lightweigh…

I think the argument was that the standard states that setenv is not thread safe, although from what I see it says that it does not have to be thread safe: The setenv( ) function need not be thread-safe. A function that is not required to be thread-safe is not required to be reentrant. https://www.open-std.org/jtc1/sc22/open/n4217.pdf . Page.. 1860 :')

Sure, but given that Linux defines the environment as state that's shared between threads, not having a thread-safe way of accessing it is hard to defend...

Is "the standard says it doesn't NEED to be thread safe" the argument that the Linux libc maintainers are using for not enhancing it to be thread safe, or is it based on some technical or backwards compatibility issues in doing so ?

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

#282

Post by Joker_vD » Thu, Jan 23, 2025, 4:17 PM UTC

account42 wrote: post #239

Joker_vD wrote: post #105

Earlier quoted context omitted.

The process's current directory is mutable global state as well, and yet chdir(2) is thread-safe.

It's threadsafe in the memory sense. It's not threadsafe in the having an idea what files you are accessing sense.

The latter is always true even when you don't use chdir(2) and/or always use absolute file paths since, you know, there are other processes that can re-arrange the file system whatsoever way the like. The file system is one example of the unavoidable global mutable shared state (another example is network) which one simply has to deal with.

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

#283

Post by colonial » Thu, Jan 23, 2025, 4:18 PM UTC

TIL 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

#284

Post by layer8 » Thu, Jan 23, 2025, 4:24 PM UTC

benmmurphy wrote: post #142

rerdavies wrote: post #123

Earlier quoted context omitted.

Why does adding a mutex break the API? I guess it breaks `char**environ`. But the API wouldn't be broken.

I think you would have to change the API to return a copy of the string as the get_env result which the caller is responsible for free-ing or the env implementation would have to ensure returned values from get_env are stable and never change which is effectively a memory leak.

Getenv_r() does this: https://man.netbsd.org/getenv_r.3

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

#285

Post by dboreham » Thu, Jan 23, 2025, 4:25 PM UTC

saagarjha wrote: post #210

vrtx0 wrote: post #201

Earlier quoted context omitted.

I provided a copy/paste from the site about the envp array size you asked about. I clarified why I mentioned fork(). I tried to explain the difference between registers and variables. I’m not trying to show off or bring anyone down… I just like to help people. I’m old (my first Linux kernel commit was in 2004). And I could be wrong — please LMK if I made a factual error (I’d appreciate it, honestly). All good?

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…

Is it possible you're replying to LLM generated posts?

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

#286

Post by PaulDavisThe1st » Thu, Jan 23, 2025, 4:45 PM UTC

saagarjha wrote: post #203

PaulDavisThe1st wrote: post #90

Earlier quoted context omitted.

One of the major differences between X Window and the win32 GUI APIs is that the windows one builds in thread safety, and it cannot be removed. This means that you pay the price of mutexes and the like (what the windows world likes to call "critical sections"), even if you have a single threaded GUI. X Window, on the other hand, decided to do nothing about threads at all, leaving it up to the application. 30 years af…

Meanwhile, macOS will check if the application is single threaded and if so avoid using locks: https://developer.apple.com/documentation/foundation/nsthrea...

Errr, not really.

"If you detached a thread in your application using a non-Cocoa API, such as the POSIX or Multiprocessing Services APIs, this method could still return NO."

Also, I've never heard of this behavior despite years developing for macOS (admittedly tangentially). I don't see how that could work given that threads can come and go during the life of the application.

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

#287

Post by saagarjha » Thu, Jan 23, 2025, 4:53 PM UTC

PaulDavisThe1st wrote: post #286

saagarjha wrote: post #203

Earlier quoted context omitted.

Meanwhile, macOS will check if the application is single threaded and if so avoid using locks: https://developer.apple.com/documentation/foundation/nsthrea...

Errr, not really. "If you detached a thread in your application using a non-Cocoa API, such as the POSIX or Multiprocessing Services APIs, this method could still return NO." Also, I've never heard of this behavior despite years developing for macOS (admittedly tangentially). I don't see how that could work given that threads can come and go during the life of the application.

Yes, really: https://developer.apple.com/library/archive/documentation/Co.... This also outlines what you have to do if you use POSIX threads.

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

#288

Post by wizzwizz4 » Thu, Jan 23, 2025, 4:53 PM UTC

saagarjha wrote: post #187

dietr1ch wrote: post #172

Earlier quoted context omitted.

Which programming languages? When using C++ I wanted programs to have a function that was called before main() and set up things that got sealed afterwards, like parsing command-line-arguments, the environment variables, loading runtime libraries, and maybe look at the local directory, but I'm not sure if it'll be a useful and meaningful distinction unless you restructure way too many things. I remember that on the F…

Everyone thinks they are can be the first to do something, and that there is surely nothing that will happen before them. Unfortunately everyone save for one is mistaken. Sometimes that chosen one is not even consistent.

If everyone is responsible for maintaining the illusion that someone else is first, who's actually first is largely irrelevant.

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

#289

Post by saagarjha » Thu, Jan 23, 2025, 4:54 PM UTC

dboreham wrote: post #285

saagarjha wrote: post #210

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…

Is it possible you're replying to LLM generated posts?

Of course. The reply remains relevant either way.

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

#290

Post by fch42 » Thu, Jan 23, 2025, 4:55 PM UTC

gpderetta wrote: post #254

o11c wrote: post #175

Earlier quoted context omitted.

If you only consider `getenv`/`setenv` there are indeed many solutions, but it's not that simple. You also need to consider `putenv` (not that nasty, you just need to treat it like initial environment, which means you can't use a single range check) and accessing the `environ` variable directly (nasty). Your particular solution doesn't work because people expect `getenv` to be async-signal-safe, which means you shoul…

> accessing the `environ` variable directly (nasty). "easy": protect the page containing environ and handle the mutation from the signal handler. /s of course.

"mutating" there involves the need to (re)allocate memory. To do so in a signal handler is hard ... because memory allocators are, while threadsafe, not async-signal-safe. You can't make a hard problem easy by asserting dependence on another (unsolved) hard problem.

Btw, you can _also_ substitute libc's setenv/getenv/putenv with your own (locking) implementations, courtesy preload and all the funky features of ELF symbol resolution. Actually easy. But impossible if you link against static code using it (go ... away). Hmm. easy ? impossible ? damn this grey world. Gimme some color.