Don't setenv in multi-threaded code on glibc

Re:Don't setenv in multi-threaded code on glibc by deathanatos on Tuesday January 31, 2017 @12:20PM (#13532747)

> FreeBSD libc does similar with getenv, in that the returned environment is a snapshot of that point in time.

How does FreeBSD's libc know when to free that snapshot? (Since there is no "free the env snapshot you gave me" call.) If thread B calls getenv, how does that not invalidate the snapshot that thread A has?

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by MaulingMonkey on Tuesday January 31, 2017 @01:02PM (#13533301)

Thread local storage would let you store a snapshot for thread A until thread A itself re-invokes getenv.

Other comments seem to imply this isn't what FreeBSD is doing however.

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by quotemstr on Tuesday January 31, 2017 @01:08PM (#13533361)

So what if you call getenv twice?

    const char* foo = getenv("FOO");
    const char* bar = getenv("BAR");

foo and bar should both be valid here. Sure, you could allocate an arbitrary amount of thread-local storage, but that's still a leak.

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by MaulingMonkey on Tuesday January 31, 2017 @01:13PM (#13533411)

Guess there's a reason FreeBSD isn't doing it :D.

[ Parent | on HN ]