4 ms·

I’ve been searching around, and you can find a bunch of discussions about this online. Your ’sarcastic’ argument is basically the one I’ve seen in most places.

by jrmg 3y ago

I’ve been searching around, and you can find a bunch of discussions about this online. Your ’sarcastic’ argument is basically the one I’ve seen in most places. They could easily be made thread safe, but, paraphrasing, most arguments seem to come down to something like: “setenv and getenv are POSIX functions, and not defined to lock. Just like many POSIX functions, they’ve _never_ been thread safe, and it’s an error to assume they are. Should we really start papering over client errors in use of a supposedly portable API, even though it’s working as specified? And if we make that choice pragmatically for this instance, should we be trying to do it for _all_ of POSIX? That’s impossible for some things, and would add complexity even where it’s not. For all these reasons, it’s better if these just stay dangerous like they’ve always been.”

jiggawatts 3y ago
This kind of historical baggage is one of the main reasons I now completely avoid C/C++ programming and won't touch it ever again. It's Rust or C# only for me from here on...
- thayne 3y ago
  The problem is that this effects higher languages too, because they often build on libc. And on some OSes, they don't have a choice, because the system call interface is unstable and/or undocumented). For example in rust, multiple time libraries were found to be unsound if `std::env::set_env` was ever called from a multi-threaded program. See: https://github.com/time-rs/time/issues/293 https://github.com/time-rs/time/issues/293 and https://github.com/chronotope/chrono/issues/499 https://github.com/chronotope/chrono/issues/499 https://github.com/rust-lang/rust/issues/27970 https://github.com/rust-lang/rust/issues/27970 https://github.com/rust-lang/rust/issues/90308 https://github.com/rust-lang/rust/issues/90308
Taniwha 3y ago
Yes it's worth remembering that the POSIX base came before threads became commonly available (or even had a standardised API)
- thayne 3y ago
  Maybe it is time to replace the POSIX base with something that is better suited to a multi-threaded environemnt.
  - FridgeSeal 3y ago
    I’ll go one further and say that maybe it’s time we had OS’/kernel/API base that isn’t just better suited, but is explicitly designed for the massively multithreaded, ludicrously fast, massively concurrent hardware we have in spades these days. Alas I am not as OS dev, I have not the skills or understanding to not how to build that, or what this would involve, but I do think it’s clear that what we have at the moment isn’t as well suited as it could be. Io_uring / Direct-IO seem to be better suited though.
  - pjmlp 3y ago
    Which is already happening on non UNIX OSes. Even on OSes that happen to use the Linux kernel like Android, those that insist on using the NDK and pretend it is like GNU/Linux, beyond the official supported use cases, end up bumping their heads against the wall.
wmf 3y ago
This is fine for a 1980s monolithic program but if you use any library that reads environment variables (like, ahem, libc!) you have to treat the whole library as non-thread-safe? Or keep track of the "color" of each library function?

by jrmg 3y ago

jiggawatts 3y ago

This kind of historical baggage is one of the main reasons I now completely avoid C/C++ programming and won't touch it ever again. It's Rust or C# only for me from here on...

thayne 3y ago
The problem is that this effects higher languages too, because they often build on libc. And on some OSes, they don't have a choice, because the system call interface is unstable and/or undocumented). For example in rust, multiple time libraries were found to be unsound if `std::env::set_env` was ever called from a multi-threaded program. See: https://github.com/time-rs/time/issues/293 https://github.com/time-rs/time/issues/293 and https://github.com/chronotope/chrono/issues/499 https://github.com/chronotope/chrono/issues/499 https://github.com/rust-lang/rust/issues/27970 https://github.com/rust-lang/rust/issues/27970 https://github.com/rust-lang/rust/issues/90308 https://github.com/rust-lang/rust/issues/90308

Taniwha 3y ago

Yes it's worth remembering that the POSIX base came before threads became commonly available (or even had a standardised API)

thayne 3y ago
Maybe it is time to replace the POSIX base with something that is better suited to a multi-threaded environemnt.
- FridgeSeal 3y ago
  I’ll go one further and say that maybe it’s time we had OS’/kernel/API base that isn’t just better suited, but is explicitly designed for the massively multithreaded, ludicrously fast, massively concurrent hardware we have in spades these days. Alas I am not as OS dev, I have not the skills or understanding to not how to build that, or what this would involve, but I do think it’s clear that what we have at the moment isn’t as well suited as it could be. Io_uring / Direct-IO seem to be better suited though.
- pjmlp 3y ago
  Which is already happening on non UNIX OSes. Even on OSes that happen to use the Linux kernel like Android, those that insist on using the NDK and pretend it is like GNU/Linux, beyond the official supported use cases, end up bumping their heads against the wall.

wmf 3y ago

This is fine for a 1980s monolithic program but if you use any library that reads environment variables (like, ahem, libc!) you have to treat the whole library as non-thread-safe? Or keep track of the "color" of each library function?