A good write up that summarizes my criticism to the often sclerotic POSIX standard.
The argument for getenv/setenv can be extended to many other POSIX functions. You'll find countless functions in the specs that state "this function is not thread-safe. If you wanna use it in a threaded environment, you're on your own".
Many bugs in a lot of today's software can be traced back the POSIX functions stubbornly refusing to be thread-safe.
When reading the specs of several POSIX functions, you often have that feeling that everything is only supposed to be used in single-threaded applications like it's 1985.
To be fair, I understand part of the argument for not making many of these functions thread-safe. Functions like getenv/setenv return copies to static char* pointers shared across threads. Either setenv allocates a new immutable copy of the buffer that can't be freed (glibc, Solaris), which means that basically each call to setenv amounts to a memory leak, or it returns a pointer to a shared static area of memory (musl, BSD, Apple) that is subject to crash if two threads try and access it at the same time.
(Btw, only getenv is part of the ANSI C standard, not setenv, and you may see the reason now. So a pure ANSI C program is allowed to read environment variables, but not to write them).
But hey, it's not longer 1985. I'm not sure if I'm missing something obvious here, but I don't see why the libc couldn't simply add a layer of read/write locks to shared areas of memory, taking the burden of setting up such abstractions away from the application developers. It could even extend those functions with a `*_safe` prefix, if we don't want to break back-compatibility or impact performance on other applications. Yes, it almost sounds like re-implementing the Python's GIL, but the scope can definitely be more granular than that if we want to prevent the GIL's overhead.
The solution can't be to just kick the can down the road, accept that some arcane bugs have existed for the past four decades and will probably keep being around for the next four, expose all the internals of memory management to the application developer, and let each single application implement their own thread-safety layer if they need to.
https://www.evanjones.ca/setenv-is-not-thread-safe.html
Fabio Manganiello /
npub1v7…ukv0u
2023-11-20 10:15:56
Author Public Key
npub1v78mmuz20p6qd6nve30axhqu74avwn4f6z4grhug7755rat7wh3syukv0uPublished at
2023-11-20 10:15:56Event JSON
{
"id": "4b44d05c052250a2eb9574c640b86ac753f9f9192e43b74545084f38a38bb094",
"pubkey": "678fbdf04a787406ea6ccc5fd35c1cf57ac74ea9d0aa81df88f7a941f57e75e3",
"created_at": 1700475356,
"kind": 1,
"tags": [
[
"proxy",
"https://social.platypush.tech/users/blacklight/statuses/111442352973000753",
"activitypub"
]
],
"content": "A good write up that summarizes my criticism to the often sclerotic POSIX standard.\n\nThe argument for getenv/setenv can be extended to many other POSIX functions. You'll find countless functions in the specs that state \"this function is not thread-safe. If you wanna use it in a threaded environment, you're on your own\".\n\nMany bugs in a lot of today's software can be traced back the POSIX functions stubbornly refusing to be thread-safe.\n\nWhen reading the specs of several POSIX functions, you often have that feeling that everything is only supposed to be used in single-threaded applications like it's 1985.\n\nTo be fair, I understand part of the argument for not making many of these functions thread-safe. Functions like getenv/setenv return copies to static char* pointers shared across threads. Either setenv allocates a new immutable copy of the buffer that can't be freed (glibc, Solaris), which means that basically each call to setenv amounts to a memory leak, or it returns a pointer to a shared static area of memory (musl, BSD, Apple) that is subject to crash if two threads try and access it at the same time.\n\n(Btw, only getenv is part of the ANSI C standard, not setenv, and you may see the reason now. So a pure ANSI C program is allowed to read environment variables, but not to write them).\n\nBut hey, it's not longer 1985. I'm not sure if I'm missing something obvious here, but I don't see why the libc couldn't simply add a layer of read/write locks to shared areas of memory, taking the burden of setting up such abstractions away from the application developers. It could even extend those functions with a `*_safe` prefix, if we don't want to break back-compatibility or impact performance on other applications. Yes, it almost sounds like re-implementing the Python's GIL, but the scope can definitely be more granular than that if we want to prevent the GIL's overhead.\n\nThe solution can't be to just kick the can down the road, accept that some arcane bugs have existed for the past four decades and will probably keep being around for the next four, expose all the internals of memory management to the application developer, and let each single application implement their own thread-safety layer if they need to.\n\nhttps://www.evanjones.ca/setenv-is-not-thread-safe.html",
"sig": "0435a5970eae4c64a8f6adc61606879716382ce58404df11a68b0676210caf14a5d8d56da800770d6ebf3d01f056acf219bdcbb8ceb2c16cb73e051734ca6ba4"
}