[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Jun 2017 09:49:59 +1000
From: Patrick Oppenlander <pattyo.lists@...il.com>
To: musl@...ts.openwall.com
Subject: Re: detect timezone changes by monitoring /etc/localtime (like
glibc)
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
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.
