[tz] Thread-safe localtime(3) (was Re: Reading binary files)
christos at zoulas.com
Wed Nov 2 22:49:01 UTC 2011
On Nov 2, 12:08pm, guy at alum.mit.edu (Guy Harris) wrote:
-- Subject: Re: [tz] Thread-safe localtime(3) (was Re: Reading binary files)
| >From a quick look at the NetBSD APIs, we have:
| timezone_t tzalloc(const char *name);
| takes a time zone name as an argument, and returns NULL on failure to load that zone and a timezone_t (an opaque handle, implemented as a pointer to an opaque structure) on success
| void tzfree(const timezone_t sp);
| releases the result of tzalloc()
| struct tm *localtime_rz(const timezone_t sp, const time_t * __restrict timep, struct tm *tmp);
| given a timezone_t and a time_t, fills in a struct tm - presumably returns the struct tm * passed to it
| time_t mktime_z(const timezone_t sp, struct tm *tmp);
| given a timezone_t and a struct tm, returns a time_t
| size_t strftime_z(const timezone_t sp, char * const s, const size_t maxsize, const char * const format, const struct tm * const t);
| given a timezone_t, a struct tm, and a format, fills in a string with the time formatted according to the string
| Presumably the timezone_t is needed for the time zone name, as
No, it is the loaded tzstate.
| 1) even if NetBSD might have tm_gmtoff and tm_zone fields in struct tm, not all systems will necessarily have it
| 2) even if it does, the problem of "what happens if tm_zone points to something in the timezone state and that gets freed before a reference is made to the struct tm?" remains.
You document that you cannot free the timezone_t if you want to keep using
| I think having APIs that explicitly take a loaded time zone as an argument is something we should do, as thread safety isn't the only issue; there are reasons to have more than one time zone used for time conversions within a given single thread of control.
That is what has been done; why do you think otherwise?
More information about the tz