This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: zonefile changes and long running processes.


On 05/03/2014 01:52 AM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> That is not correct, tzset is MT-safe, and documented in the glibc 
>> manual as such.
> 
> Sorry, my use of the term "thread-safe" was incorrect.  I was
> thinking of the problem of ensuring that a thread that calls
> localtime_r is insulated from another thread simultaneously calling
> tzset, i.e., that the tzset will appear to occur either all before or
> all after the localtime_r.  As far as I know MT-Safe does not imply
> this sort of atomicity, so an application cannot assume it.

That's right, POSIX says nothing about the happens-before or happens-after
conditions on the "as if it called tzset" statement. Thus you can't
prove anything about the behaviour. A call to localtime_r may or may not
get the new zoneinfo applied or not, but you don't know.

However, in glibc we use a lock to serialize between localtime and
localtime_r.

One might argue that since POSIX tries to avoid data races, and correct
operation should be data race free, it stands to reason you get either
the new locale or the old locale but don't know which.

>> Having tzset be MT-safe will not slow down localtime_r
> 
> Wouldn't having tzset and localtime_r exclude each other slow down
> localtime_r?  And if they don't exclude each other, shouldn't
> application writers avoid the abovementioned situation if they want
> localtime_r's results to be reliable?

I see what you're getting at now. Yes, having a strict definition of
happens-before or happens-after between tzset and localtime_r will
cause localtime_r to be serialized in some way against tzset that
*may* slow it down.

However, as I wrote above both localtime and localtime_r in glibc already
take the tzset lock so either you do, or you don't get the new timezone
depending on who acquired the lock first. You get no intermediate
state. We already slowdown localtime_r against localtime calls that
may themselves call tzset. However, in the case of localtime_r you take
the lock, notice you have nothing to do and release the lock after
computing the struct tm.
 
> Please bear with me here, as I'm by no means an expert on the various
> aspects of thread-safety in glibc.

Paul, I have infinite patience for any and all questions asked by
those people whom I know want to learn and help make this better for
our users. No need to apologize. I'll answer the same question a million
times... hopefully with the same answer ;-)

As I stated before, the scope of this particular thread should remain
solely fixed on zonefile changes during MT operations that use the
various time API functions. I don't want to wander afield of the original
discussion.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]