This is the mail archive of the 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.

Carlos O'Donell wrote:
The lockless algorithm probably gives much better performance for
localtime_r, and avoids taking a mutex and serializing against tzset.

Yes, lockless is typically faster than a mutex, but even lockless synchronization typically has some overhead, and localtime_r needn't suffer any synchronization overhead: it can go ahead and inspect the tables as if it were single-threaded.

>I suspect this may be why POSIX doesn't require localtime_r to
>produce reliable results when invoked "at the same time" that tzset
>is being invoked in another thread.
Define reliable? You mean you can't decide which zoneinfo will be used
because localtime_r might see the old or new one?

No, I mean that if one thread calls localtime_r while another thread is calling tzset, localtime_r might not see either the old or the new zoneinfo table; it might see some "in-between" table and produce a timestamp that doesn't correspond to either the old or the new zoneinfo table. As I understand it, POSIX allows such an implementation, so long as localtime_r doesn't crash or infinite-loop.

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