This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING^3] RFC [PATCH] BZ#1077902: New API gettimezone
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: P J P <pj dot pandit at yahoo dot co dot in>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 28 May 2014 12:59:14 -0700
- Subject: Re: [PING^3] RFC [PATCH] BZ#1077902: New API gettimezone
- Authentication-results: sourceware.org; auth=none
- References: <53629388 dot 1060301 at redhat dot com> <53630B0C dot 1050305 at cs dot ucla dot edu> <53633A37 dot 7060405 at redhat dot com> <5363E223 dot 7060303 at cs dot ucla dot edu> <1399061963 dot 56150 dot YahooMailNeo at web192404 dot mail dot sg3 dot yahoo dot com> <1401211363 dot 50264 dot YahooMailNeo at web192402 dot mail dot sg3 dot yahoo dot com> <20140527180827 dot GA25042 at domone dot podge> <538533EB dot 3000501 at cs dot ucla dot edu> <20140528085726 dot GA975 at domone dot podge> <5385F400 dot 2070201 at cs dot ucla dot edu> <20140528182830 dot GA8314 at domone dot podge>
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.