[PING^3] RFC [PATCH] BZ#1077902: New API gettimezone

[Paul Eggert]

On 05/28/2014 11:28 AM, Ondřej Bílka wrote:
> It is not that slow as a multithread application must do locking
> somewhere to get predicable results

Sure, but I thought we had established that localtime_r itself need not 
do any locking, because a portable application can't expect predictable 
results if it runs localtime_r in one thread while running tzset in another.

> This code is only 2.5 slower than calling localtime_r when uncontended
> on haswell.

It depends on what one means by "not that slow".  To me, 2.5x slower 
than localtime_r is really slow.

Plus, we should do a better job when multiple threads invoke localtime 
near-equivalents simultaneously.  localtime_r already has an unnecessary 
bottleneck due to an unnecessary lock. It would be better to make 
localtime_r faster, instead of using its slowness to justify an API 
that's slower yet.