From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11466 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: detect timezone changes by monitoring /etc/localtime (like glibc) Date: Mon, 12 Jun 2017 19:19:18 -0400 Message-ID: <20170612231918.GE1627@brightrain.aerifal.cx> References: <488f8d57-555b-9328-f768-5779ea8aa8ec@gmail.com> <20170609121502.GO1627@brightrain.aerifal.cx> <4c950249-6330-543c-4279-3291bf4ead58@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1497309574 3217 195.159.176.226 (12 Jun 2017 23:19:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Jun 2017 23:19:34 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11479-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 13 01:19:30 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dKYcK-0000VW-7j for gllmg-musl@m.gmane.org; Tue, 13 Jun 2017 01:19:28 +0200 Original-Received: (qmail 12216 invoked by uid 550); 12 Jun 2017 23:19:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12196 invoked from network); 12 Jun 2017 23:19:31 -0000 Content-Disposition: inline In-Reply-To: <4c950249-6330-543c-4279-3291bf4ead58@gmail.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11466 Archived-At: On Tue, Jun 13, 2017 at 09:08:15AM +1000, Patrick Oppenlander wrote: > On 09/06/17 22:15, Rich Felker wrote: > >On Fri, Jun 09, 2017 at 05:15:40PM +1000, Patrick Oppenlander wrote: > >>During some recent testing I came across a bug when adjusting timezones on an > >>embedded system by changing /etc/localtime. The cause ended up being a > >>behavioural difference between glibc and musl. > > > >This difference is intentional; I believe there are past discussions > >in the list archives. > > > > I found https://marc.info/?l=musl&m=141374003126007&w=2 which was helpful. Nice, I'd forgotten about that. > Performance could be addressed (inotify?) but it's all moot anyway given > the other issues mentioned. I don't think it's as easy as you make it sound. With inotify you still need a syscall to determine whether there's an event on the inotify fd and read it. Non-blocking read() might be faster than stat() but it's still at least 500 times slower then just checking that the environment variable hasn't changed. There may be a way to wire up a signal to fire when the inotify fd has data ready, but then you consume an extra signal for implementation-internal use and have to deal with managing it. > >In order for asynchronous timezone changes to be safe, the API would > >have to be such that you make one call to get the current timezone, > >then pass it as an argument to functions depending on the timezone, so > >that the application has control of which timezone is getting used in > >each call. > > This is how the WIN32 API is implemented. The glibc developers have discussed a new time[zone] API where timezones are data objects rather than hidden global state. It might be worth reading up on what they have in mind and if there are improvements that should be suggested, and if the results could be proposed as a standard. Rich