This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: zonefile changes and long running processes.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 14 May 2014 10:17:57 +0200
- Subject: Re: zonefile changes and long running processes.
- Authentication-results: sourceware.org; auth=none
- References: <53633D96 dot 6070306 at redhat dot com> <5363DD40 dot 2040408 at cs dot ucla dot edu> <53642A07 dot 1040107 at redhat dot com> <53648418 dot 6000301 at cs dot ucla dot edu> <536AE8E0 dot 8090907 at redhat dot com> <536B16A3 dot 1010403 at cs dot ucla dot edu> <20140513211452 dot GD15468 at domone dot podge> <5372918B dot 2090407 at cs dot ucla dot edu> <20140513223354 dot GA17555 at domone dot podge> <5372C55A dot 70800 at cs dot ucla dot edu>
On Tue, May 13, 2014 at 06:22:34PM -0700, Paul Eggert wrote:
> OndÅej BÃlka wrote:
> >On Tue, May 13, 2014 at 02:41:31PM -0700, Paul Eggert wrote:
> >>does POSIX allow localtime_r to have
> >>undefined behavior if some other thread is simultaneously invoking
> >>tzset?
> >
> >yes, it would as is now.
>
> If POSIX says that, then what does it mean for tzset and localtime_r
> to be thread-safe? If localtime_r can crash the system whenever
> another thread is calling tzset, how can that be considered
> "thread-safe"?
>
> >A simplest solution would be replace mutex there with rwlock so
> >localtime do not block each other.
> >
> >A faster solution would be add counter for localtime_r, a tzset would
> >free previous buffers when a counter is zero, otherwise it would just
> >add a buffer to list of buffers that should be freed.
>
> All of these slow down localtime_r, if only somewhat. Can't
> localtime_r run full-speed, without worrying about getting a lock or
> adding to a counter or whatnot? After all, localtime_r is not
> required to be atomic; it's required only to be thread-safe.
Could but it would not make a big difference, a localtime call takes 2000 cycles,
a rwlock/counter would definitely fit to 500 cycles in worst case when
there is no tzset and hardware supports atomics.
As we do not free a timezone string we could do same, construct
immutable structure with precomputed data that and look if there is
already such structure. It would take only one read for localtime_r
which is fast enough.