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: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 14 May 2014 00:33:54 +0200
- Subject: Re: zonefile changes and long running processes.
- Authentication-results: sourceware.org; auth=none
- References: <53633734 dot 5010406 at redhat dot com> <53633965 dot 3010606 at cs dot ucla dot edu> <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>
On Tue, May 13, 2014 at 02:41:31PM -0700, Paul Eggert wrote:
> On 05/13/2014 02:14 PM, OndÅej BÃlka wrote:
> >tzstruct *ptr;
> >void tz_set_internal (tzstruct *set)
> >{
> > tzstruct *old = atomic_exchange_acq (&ptr, set);
> > if (old->malloced)
> > free (old);
> >}
>
> With this implementation, couldn't a tzset in one thread crash a
> localtime_r running in another thread? E.g., won't trouble occur if
> the other thread's localtime_r implementation accesses the malloced
> storage at the same time the tzset thread invokes "free (old)"?
> POSIX allows some leeway here, and I presume we want to exploit that
> to improve performance, but does POSIX allow localtime_r to have
> undefined behavior if some other thread is simultaneously invoking
> tzset?
yes, it would as is now.
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.