undefined | Better HN

0 pointsfsckboy1y ago0 comments

you've gotten a lot of answers which say the same thing, but which I don't think answer your question:

synchronization methods impose various complexity and performance penalties, and single threaded applications which don't need that would pay those penalties and get no benefit.

Unix was designed around a lightweight ethos that allowed simple combining of functions by the user on the command line. See "worse is better", but tl;dr that way of doing things proved better, and that's why you find yourself confronting what it doesn't do.

0 comments

davidt841y ago

The real problem is that getenv() and setenv() were created before threads were really a thing.

kazinator1y ago

getenv can easily be misused in a single threaded program.

davidt841y ago

But it is possible to safely use it in a single threaded program.

There's no way to use it safely in a multi threaded application that may use setenv (unless you add your own synchronisation, and ensure everything uses it, even third party libraries).

1 more reply

sunshowers1y ago

Well it was better in the short term but is worse in the long term. In particular, the error handling situation is generally atrocious, which is fine for interactive/sysadmin use but much worse for serious production use.

j / k navigate · click thread line to collapse

0 comments

davidt841y ago

The real problem is that getenv() and setenv() were created before threads were really a thing.

kazinator1y ago

getenv can easily be misused in a single threaded program.

davidt841y ago

But it is possible to safely use it in a single threaded program.

There's no way to use it safely in a multi threaded application that may use setenv (unless you add your own synchronisation, and ensure everything uses it, even third party libraries).

1 more reply

sunshowers1y ago

j / k navigate · click thread line to collapse