Date: Thu, 5 Mar 2015 09:59:44 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: getenv_r * William Ahern <william@...handClement.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)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.