A good write up that summarizes my criticism to the often sclerotic POSIX standard - yes, I love it, but, like in all relations, nobody is supposed to love forever something that refuses any form of change.
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.
It's almost like if the specs were telling us "you have to read the documentation of each of these functions before using them, so you'll know how they can break, and you're only supposed to use them in single-threaded applications like it's 1985".
What infuriates me is that it's almost trivial to implement a multilock read/write map-based mechanism for environment variables. But POSIX stubbornly refuses to do so, it keeps seeing threads as some experimental feature that the standard isn't even supposed to fully support, and thousands of developers around the world are supposed to implement this mechanism themselves once their application crashes on a getenv.
We deserve better than this.
https://www.evanjones.ca/setenv-is-not-thread-safe.html
Fabio Manganiello
npub1v7…ukv0u
2023-11-20 09:48:45 UTC
Author Public Key
npub1v78mmuz20p6qd6nve30axhqu74avwn4f6z4grhug7755rat7wh3syukv0uPublished at
2023-11-20 09:48:45 UTCEvent JSON
{
"id": "42848e4410d9e61b3733018c51bf611f6cdd933c705e526ee25c8e23a2e8d540",
"pubkey": "678fbdf04a787406ea6ccc5fd35c1cf57ac74ea9d0aa81df88f7a941f57e75e3",
"created_at": 1700473725,
"kind": 1,
"tags": [
[
"proxy",
"https://social.platypush.tech/users/blacklight/statuses/111442246066544234",
"activitypub"
]
],
"content": "A good write up that summarizes my criticism to the often sclerotic POSIX standard - yes, I love it, but, like in all relations, nobody is supposed to love forever something that refuses any form of change.\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\nIt's almost like if the specs were telling us \"you have to read the documentation of each of these functions before using them, so you'll know how they can break, and you're only supposed to use them in single-threaded applications like it's 1985\".\n\nWhat infuriates me is that it's almost trivial to implement a multilock read/write map-based mechanism for environment variables. But POSIX stubbornly refuses to do so, it keeps seeing threads as some experimental feature that the standard isn't even supposed to fully support, and thousands of developers around the world are supposed to implement this mechanism themselves once their application crashes on a getenv.\n\nWe deserve better than this.\n\nhttps://www.evanjones.ca/setenv-is-not-thread-safe.html",
"sig": "3302020a682e692c93d2d237fd3f0cd4981c6b148be0034d17bce7eb1b6dec0f84082bf06d7eed696ad13bfe6f4c12db2c993d2fb525e89d16035b2a711ba92d"
}