Re: getenv_r

[Szabolcs Nagy <nsz@port70.net>]

* William Ahern <william@25thandClement.com> [2015-03-04 17:34:57 -0800]:
> On Thu, Mar 05, 2015 at 01:41:33AM +0100, Szabolcs Nagy wrote:
> > in a multi-threaded application environ modification
> > is unsafe and problematic even if you do the locks:
> > different threads may want different value for an env
> > var and when you read an env var you cannot know if
> > it is up to date when you want to use it.

> 
> One obvious use for a thread-safe setenv and getenv is when trying to
> generate a time_t timestamp from a UTC struct tm. timegm is not standard.
> The glibc manual page suggests to instead set the TZ environment variable to
> UTC, call tzset, call mktime, restore TZ, and call tzset again.
> 

this is exactly the use-case i warned against:
in a multi-threaded application where libraries do this
TZ will be clobbered concurrently

> But really the issue is most intractable in my position, where I'm trying to
> implement a bindings module. In Lua especially, where the Lua VM has no
> global state, it's simple to run Lua scripts in a multi-threaded environment
> and have them mostly just work without issue. But those scripts are
> exceedingly unlikely to have been concerned with thread-safety, and with
> setenv being unsafe to use. And they can't be expected to use
> synchronization primatives because module A might have no relationship to
> module B.

as i said multi-threaded code should not call setenv

that fixes all issues

the locking fixes no issues (at least you could not
demonstrate a valid use-case yet)