3 ms·
Should apps orchestrate a super-global lock of a foreign namespace? An environment variable's value, for a running process, is just what it is: an initial valu
by turtleyacht 3y ago
Should apps orchestrate a super-global lock of a foreign namespace?
An environment variable's value, for a running process, is just what it is: an initial value from outside.
Adding complexity around it smells like an attempt to control a distributed mutex, like checking an API for real-time value changes in a while loop across several instances of the same app.
I thought there would be alternatives to this, like pubsub, Kafka, or other asynchronous event handling.
Imagine having to test an app for its ability to handle safe read-write of OS-level state. It's definitionally bankrupt: not really a unit, not easy to set up quickly, and not isolated.
- xxs 3y ago>Imagine having to test an app for its ability to handle safe read-write of OS-level state. I Also it should be able to handle invariants as modifying multiple variables is not an atomic process, either.
- aidenn0 3y ago> An environment variable's value, for a running process, is just what it is: an initial value from outside. Then calling setenv() from anywhere except in the time between a fork() and exec() call should be banned, but it's not. Honestly, calling abort() if setenv is called in the presence of threads would seem like a better status-quo than what we have today.
- nwmcsween 3y agoAnd how do you propose banning it? Should libc track function calls? Maybe when the linker links setenv we just print out the man page for setenv.