On 11/10/2016 02:04 PM, Guy Harris wrote:
I don't see an easy way around this problem with the current Darwin API. With the current*UNIX* API.
The NetBSD API gives applications a way to get an immutable time zone object, so that multiple operations like localtime_rz and mktime_z can use consistent rules. This was originally designed for multithreading (so that different threads can be in different time zones) but it also has the property that time zone rules don't change once determined (which helps performance). Emacs uses this API if available, so Emacs should be reasonably immune to these races on NetBSD. NetBSD doesn't look for changes to the installed tz binary files, as Darwin does. If the NetBSD API were implemented atop Darwin, perhaps the Darwin tzalloc operation should have a flag specifying whether the caller wants the time zone object to be immutable or potentially updated after every call. Come to think of it, perhaps we should add a options arg to the reference tzalloc too (for compatibility we'd define a new function like tzalloc but with an option arg). One option could be whether the implementation should revisit the installed tz binary file every time localtime_rz or mktime_z is called (for efficiency perhaps it could use file notification on systems where that works well). Another option, while we're on the topic, could be whether to count leap seconds. I'll CC: this to Christos Zoulas (the NetBSD time guru) to see whether he thinks this sort of thing would be a good idea.
I don't know what Emacs is trying to compute, but perhaps there needs to be an API that atomically gives it what it's trying to compute
Emacs is inferring the daylight-saving rules by making multiple calls to localtime. Essentially, Emacs wants a consistent and complete snapshot of the current rule set for all times from now into the indefinite future. Unfortunately, the API to support this sort of thing would be complicated.