From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7149 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: getenv_r Date: Thu, 5 Mar 2015 09:59:44 +0100 Message-ID: <20150305085944.GJ16260@port70.net> References: <20150304230920.GA21838@wilbur.25thandClement.com> <20150305004133.GI16260@port70.net> <20150305013457.GA20317@wilbur.25thandClement.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1425546003 18701 80.91.229.3 (5 Mar 2015 09:00:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Mar 2015 09:00:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7162-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 05 10:00:03 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YTRdS-0001xS-TA for gllmg-musl@m.gmane.org; Thu, 05 Mar 2015 10:00:02 +0100 Original-Received: (qmail 29848 invoked by uid 550); 5 Mar 2015 09:00:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29802 invoked from network); 5 Mar 2015 08:59:56 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20150305013457.GA20317@wilbur.25thandClement.com> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7149 Archived-At: * William Ahern [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)