Date: Thu, 5 Dec 2013 11:40:22 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files 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
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.