From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4373 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files Date: Thu, 5 Dec 2013 11:40:22 -0500 Message-ID: <20131205164022.GK24286@brightrain.aerifal.cx> References: <5294EE35.8040603@skarnet.org> <20131126233212.GE24286@brightrain.aerifal.cx> <529570BB.2060804@skarnet.org> <20131127042550.GI24286@brightrain.aerifal.cx> <529588D8.3020006@skarnet.org> <20131127184307.GN1685@port70.net> <52965735.9070409@skarnet.org> <529FD33A.8000509@skarnet.org> <20131205144311.GG24286@brightrain.aerifal.cx> <52A0AA6A.60608@skarnet.org> 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 1386261630 12811 80.91.229.3 (5 Dec 2013 16:40:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Dec 2013 16:40:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4377-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 05 17:40:36 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Vobyd-0005Od-BZ for gllmg-musl@plane.gmane.org; Thu, 05 Dec 2013 17:40:35 +0100 Original-Received: (qmail 23613 invoked by uid 550); 5 Dec 2013 16:40:34 -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 23600 invoked from network); 5 Dec 2013 16:40:34 -0000 Content-Disposition: inline In-Reply-To: <52A0AA6A.60608@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4373 Archived-At: On Thu, Dec 05, 2013 at 04:31:38PM +0000, Laurent Bercot wrote: > > - gmtime behaves unpredictably depending on whether a function that > > loads the timezone has or has not been called prior to calling > > gmtime. > > This is indeed a bug - an oversight on my part, sorry. > Would calling do_tzset() at the beginning of gmtime_r() fix it ? Would > it be prohibitively expensive, and if so, what would be a better > solution ? The problem is that gmtime is not permitted to do so. tzset has side effects like making the globals timezone and daylight change, and certain time functions are specified to behave as if they call it, while others are not (and therefore can't). The only way I see around this is fairly invasive: possibly keeping around two timezones. Or (almost equivalent) keeping timezone and leapseconds profiles completely separate. > > - there's no synchronization in gmtime's (or gmtime_r's) access to the > > leap seconds data so the latter isn't even thread-safe. > > OK, if changing timezones during the lifetime of a process is a valid > use case, then things must be protected. There needs to be a read-only > lock around __leapsecs_add() and __leapsecs_sub(), and a read-write lock > around the setting of __leapsecs_num and abbrevs_end. I couldn't find > such a thing as a shared lock system in musl, though. Should I go for > LOCK and UNLOCK, even though it would uselessly prevent concurrent > reads, or is there a better way ? That's a good question. __mmap has such a minimal rwlock mechanism, but it's currently not sharable (it's single-instance). However presumably each use would have to check for change in the state (change in $TZ) and possibly modify the data, so I'm not even clear that rwlock would be appropriate. What's more troubling is that the locks may need to be recursive (and thus MUCH more expensive) since some functions might depend internally (IIRC they do) on being able to make multiple calls to tm/time_t conversion functions with consistent behavior, in which case they'd have to hold the lock across multiple calls which might also use internal locking. Note that the problematic aspects that are coming up are most problematic because they're affecting not just users who want leapseconds, but all users. If leapseconds affect gmtime and leapseconds depend on TZ, all the sudden these issues apply to all calls. Rich