[Bug time/16145] localtime_r etc holds lock via __tz_convert

["fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16145

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|fweimer at redhat dot com          |unassigned at sourceware dot org

--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Dave Gotwisner from comment #9)

> From the code (see my earlier comment, but pasted here again):
> 
>    /* Update internal database according to current TZ setting.
>       POSIX.1 8.3.7.2 says that localtime_r is not required to set tzname.
>       This is a good idea since this allows at least a bit more parallelism.
> */
> 
> If you look at my comment, I clearly give a path for code change that allows
> us to meet this requirement without actually using any locks or additional
> TLS variables (as walking through the code in localtime_r() mode, none of
> the variables that must be protected are actually touched, except in [rare]
> error conditions.

The global, POSIX-specified variables aren't the problem if we only write to
them for use by application code (but not for internal use).  We currently read
from __tzname in a few places, and these would have to be adjusted to use some
other way to obtain this information.

The larger problem is that we know only fairly late in the localtime_r
processing that we need to update global state beyond the POSIX variables, e.g.
when we call back from tzfile.c into tzset.c to compute future timezone
transitions based on a specified POSIX rule string.

-- 
You are receiving this mail because:
You are on the CC list for the bug.