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

Re:C stdlib isn't threadsafe and even safe Rust didn't save us by fch42 on Thursday January 23, 2025 @06:10AM (#42802874)

That is basically "what it means" if an interface is non-MT: you can call this no-problem if you know you're singlethreaded, and if you're not, find your own way to serialize (meaning: have your own locking prinitive you acquire/release where you make calls to these functions).

One could "dream of" a func that tells libc "acquire/drop this mutex of mine around get/set/putenv calls" but that'd simply move the problem - because the nifty "frameworks" would do that (independently of each other, we're sovereign and entitled frameworks around here) and race each other's state nonetheless.

[ Parent | on HN ]

Re:C stdlib isn't threadsafe and even safe Rust didn't save us by josefx on Thursday January 23, 2025 @07:56AM (#42803514)

> because the nifty "frameworks"

Malicious software exists, does that mean we should remove all threading primitives from the standard?

[ Parent | on HN ]

Re:C stdlib isn't threadsafe and even safe Rust didn't save us by fch42 on Thursday January 23, 2025 @08:38AM (#42803858)

Obviously not, but _threading_ primitives are not the subject of this post at all. Declared-as Non-threadsafe interfaces are. And of course one (as is happening here) one can argue whether all "system runtimes" shall be threadsafe. Right now though, they are not, and agreed/sanctioned standards don't require them to be. Again (also as happening here) opinions may differ whether changes-to-make-threadsafe would be bugfixes, enhancements, or (require) new interfaces. I have expressed my views on this. Happy to agree to disagree, though.

[ Parent | on HN ]