undefined | Better HN

0 pointsHarHarVeryFunny1y ago0 comments

Sure, but given that Linux defines the environment as state that's shared between threads, not having a thread-safe way of accessing it is hard to defend...

Is "the standard says it doesn't NEED to be thread safe" the argument that the Linux libc maintainers are using for not enhancing it to be thread safe, or is it based on some technical or backwards compatibility issues in doing so ?

0 comments

debugnik1y ago

The only thread-safe way to implement getenv/setenv as they currently exist is to leak the previous state when setenv allocates, such that existing pointers stay valid. The existing API simply lacks a mechanism to synchronize correctly.

Leaking would be good enough for many use cases, but it would break long-running users of setenv (mainly those with libraries abusing env vars, as in TFA), and doesn't even solve how they interact with putenv and environ. This whole API is just cursed.

Libc could of course get better APIs, like GetEnvironmentVariable on Windows, but that won't fix all existing code.

HarHarVeryFunnyOP1y ago

Do you mean pointers returned by getenv() ? Those could point to thread-local buffers that data gets copied into when getenv() is called.

debugnik1y ago

Only if we're willing to take for granted that a call to getenv invalidates the previous one. POSIX allows it, but I'm concerned about runtimes scheduling user tasks on the same thread.

If current platforms are safely making a copy of getenv before allowing their scheduler to interrupt, then yes I'd be ok with your solution.

1 more reply

j / k navigate · click thread line to collapse

0 comments

debugnik1y ago

Libc could of course get better APIs, like GetEnvironmentVariable on Windows, but that won't fix all existing code.

HarHarVeryFunnyOP1y ago

Do you mean pointers returned by getenv() ? Those could point to thread-local buffers that data gets copied into when getenv() is called.

debugnik1y ago

Only if we're willing to take for granted that a call to getenv invalidates the previous one. POSIX allows it, but I'm concerned about runtimes scheduling user tasks on the same thread.

If current platforms are safely making a copy of getenv before allowing their scheduler to interrupt, then yes I'd be ok with your solution.

1 more reply

j / k navigate · click thread line to collapse