From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11467 Path: news.gmane.org!.POSTED!not-for-mail From: Patrick Oppenlander Newsgroups: gmane.linux.lib.musl.general Subject: Re: detect timezone changes by monitoring /etc/localtime (like glibc) Date: Tue, 13 Jun 2017 09:49:59 +1000 Message-ID: <1b292bf4-b567-bbad-a6c5-7f68642434f4@gmail.com> References: <488f8d57-555b-9328-f768-5779ea8aa8ec@gmail.com> <20170609121502.GO1627@brightrain.aerifal.cx> <4c950249-6330-543c-4279-3291bf4ead58@gmail.com> <20170612231918.GE1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1497311414 10280 195.159.176.226 (12 Jun 2017 23:50:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Jun 2017 23:50:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 To: musl@lists.openwall.com Original-X-From: musl-return-11480-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 13 01:50:11 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 1dKZ62-0002NH-MN for gllmg-musl@m.gmane.org; Tue, 13 Jun 2017 01:50:10 +0200 Original-Received: (qmail 32373 invoked by uid 550); 12 Jun 2017 23:50:14 -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 32352 invoked from network); 12 Jun 2017 23:50:13 -0000 X-Virus-Scanned: amavisd-new at motec.com.au DKIM-Filter: OpenDKIM Filter v2.11.0 camber.motec.com.au 29F37177259 In-Reply-To: <20170612231918.GE1627@brightrain.aerifal.cx> Content-Language: en-AU Xref: news.gmane.org gmane.linux.lib.musl.general:11467 Archived-At: On 13/06/17 09:19, Rich Felker wrote: > On Tue, Jun 13, 2017 at 09:08:15AM +1000, Patrick Oppenlander wrote: > >> 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. > I'm fairly sure that signal notifications on inotify handles were implemented in 2.6 at some stage, however, I didn't consider the further implications of doing such a thing. > > 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. > I'm not signed up to the glibc lists, but I'll see what I can dig up. On another note, while reading the code in this area I noticed that musl mmap's the timezone file and holds pointers to the mapped area. Is this safe given that system updates often change these files? Or do we assume that no package manager is dumb enough to modify files in place? Patrick