Re: [PATCHv2] Add support for leap seconds in zoneinfo files

[Rich Felker <dalias@aerifal.cx>]

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