This is the mail archive of the
mailing list for the glibc project.
Re: zonefile changes and long running processes.
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 13 May 2014 18:22:34 -0700
- 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> <20140513223354 dot GA17555 at domone dot podge>
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
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.