Re:C stdlib isn't threadsafe and even safe Rust didn't save us
by oguz-ismail on Thursday January 23, 2025 @02:39AM
(#42801658)
>`putenv` (not that nasty,
It's equally nasty. POSIX requires that the argument to `putenv()' not be copied, so it's not very different from assigning to `environ' directly.
Re:C stdlib isn't threadsafe and even safe Rust didn't save us
by gpderetta on Thursday January 23, 2025 @07:42AM
(#42803410)
> accessing the `environ` variable directly (nasty).
"easy": protect the page containing environ and handle the mutation from the signal handler.
/s of course.
Re:C stdlib isn't threadsafe and even safe Rust didn't save us
by fch42 on Thursday January 23, 2025 @11:55AM
(#42805653)
"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.
Your particular solution doesn't work because people expect `getenv` to be async-signal-safe, which means you shouldn't be allocating memory.
Hmm ... doing an incref-like operation during `getenv` for a previously `setenv`ed variable that hasn't yet been accessed in this thread would be fine ... clear those refs during calls we know indicate knowledge refreshes ...