Date: Tue, 1 Apr 2008 21:59:09 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: David Xu <davidxu@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: localtime() vs localtime_r() Message-ID: <20080401105909.GD24181@server.vk2pj.dyndns.org> In-Reply-To: <47F05C44.9020603@freebsd.org> References: <47F05C44.9020603@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--GpGaEY17fSl8rd50
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Mar 31, 2008 at 11:36:36AM +0800, David Xu wrote:
>According POSIX specification, it seems localtime_r() is not only
>a reentrant version of localtime(), but also a performance-wise version.
IMO, localtime_r() is _not_ reentrant because it implicitly uses TZ
=66rom the environment, rather than having TZ (ither as TZ or struct
state) passed as an argument. I have an application that does
conversions between timezones and this lack is a PITA.
>Our implementation does set tzname, tomezone and daylight, it is a bit
>slower than glibc because ours has to call getenv() everytime.
Given that POSIX stuffed the definition of localtime_r(), it's not
clear how to avoid this. I guess you could change the tzset_basic()
call in localtime_r() to something like:
static initialised =3D 0;
if (!initialised) {
tzset_basic();
initialised =3D 1;
}
which means it won't see changes to TZ.
--=20
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
--GpGaEY17fSl8rd50
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)
iEYEARECAAYFAkfyFX0ACgkQ/opHv/APuIeR6QCdHwfOftuwEyES2xv2kYyFajfl
Ul8An1ztBUIsyTD5BGdOj1x86j0RpG4M
=IfCH
-----END PGP SIGNATURE-----
--GpGaEY17fSl8rd50--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080401105909.GD24181>