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

["dgotwisn at netscout dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #9 from Dave Gotwisner <dgotwisn at netscout dot com> ---
Florian, from the bug description (and reading the manual page and code),
localtime_r specifically bypasses all the timezone database stuff.  From the
manual page, localtim_r() ... stores the data in a user-supplied struct.  It
need not set tzname, timezone, and daylight.  Later, it indicates the _r
routines are thread safe.

Also, later in the NOTES section, "According to POSIX.1-2004, localtime() is
required to behave as though tzset() was called, while localtime_r() does not
have this requirement.  For portable code tzset() should be called before
localtime_r().  Working off CentOS 6.5, manual page dated 2009-03-15 for
ctime(3).

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.

Your associated wiki page describes the behavior for all but localtime_r(), as
that interface doesn't read the timezone file, etc.  It may go through the same
routines, but, because of parameters passed in, they go through the "safe"
paths.

The lock should be moved internal to code that actually needs it, not to the
outer code that doesn't (in this case).  It might be reasonable to do some code
duplication to simplify the issue (a path for localtime_r(), a path for
everything else).

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