From kde-core-devel Sat Mar 31 13:42:32 2007 From: Thiago Macieira Date: Sat, 31 Mar 2007 13:42:32 +0000 To: kde-core-devel Subject: Re: KDED time zone module Message-Id: <200703311542.35211.thiago () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117534844924723 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2505995.7tdgLOEQ22" --nextPart2505995.7tdgLOEQ22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David Jarvie wrote: >> Remember that /etc/localtime must be a copy, not a link. If it's a >> link, the local time isn't available at boot time if /usr is a >> mount-point, which in turn means the system clock will be set wrongly >> if the hardware clock isn't Universal Time. > >That explains the use of a copy rather than a link :) The code for >determining the local zone (which I didn't write originally) allows for > a link as one of the options, so perhaps on some systems a link is > used? It works too, but I guess only smart installers do that (i.e., they detect= =20 that /usr isn't a mountpoint). The default case should be a copy. The drawback of that is that the=20 zoneinfo files may get updated, but /etc/localtime won't. Of course, people should just use UTC in their hardware clocks. >> But you didn't answer the question: does that information need to be >> cached? Does it need to be shared via mmap() file? >> >> Also, why do we need that information? What are the use cases? I still don't understand why you need to find which file /etc/localtime is= =20 a copy from. Can't you simply use it as is? Or is the point finding out the timezone name? If so, what is the name=20 useful for? "Bleh/Foobar" isn't exactly portable. >1) Virtually every application which uses KDateTime or which uses any > time zones will reference the local time zone. Currently that includes > most of the kdepim applications, plus a handful of others such as > kplato and amarok, but this may well increase as people become more > aware of the classes. Because of the possible overhead in determining > the local time zone, it certainly needs to be determined only once per The local timezone is /etc/localtime or whatever the user set in $TZ. I=20 don't see any overhead in determining that. >3) The function of the kded module which is in more doubt is the > creation of the KSystemTimeZone collection, since this won't incur the > same level of processing as items 1 and 2. The kded module needs to > read and parse zone.tab (which is not a complex operation) to verify > that the local time zone actually exists on the system.=20 What if it doesn't? And see my comments above. >- The 400+ instances don't have to be created by each application. This > is probably fairly trivial since the instances are just skeletons > containing name, location etc. Agreed. If you are going to parse it and it is a lengthy operation, I=20 agree that caching is important. Making it a kded module certainly helps=20 with synchronisation and serialisation of the operation. However, you must be aware that KDateTime is too low-level. This can lead=20 to serious deadlocks if KDateTime is allowed to call out to kded at any=20 point in time, if somehow the action was triggered by D-Bus/IPC events=20 that lead back to kded. The functions that can trigger the call to kded=20 should be marked as "possibly lengthy" and should be avoided in call=20 paths that can be invoked as a result of D-Bus events. >- Data can be shared. Once an application has referenced a given time > zone, its definition data will be read from the zoneinfo directory, > parsed and stored in the relevant KSystemTimeZone instance. Subsequent > references even by other applications can use the same data without > refetching. However, it seems likely that most applications will use > very few time zones - if so, this may not be significant. I understand the need for cache. But you have not yet proven to me that=20 you need a shared cache file. Is that a lot of data to transfer over, so=20 that D-Bus is impractical? If, however, this data may be required from several points in the=20 KDateTime class, using a shared file (with a lock!) is probably better=20 than using D-Bus calls. That will be not only faster, but it will also=20 avoid deadlocks. >So the overall advantage is not so clear for this function. I still don't know what purpose a KDE-local cache of=20 the /usr/share/zoneinfo serves. I understand the need for timezone information, historical even. But given= =20 that applications will probably not use more than 4 timezones at once, I=20 fail to see the need for the cache. Is the parsing of a single timezone=20 so expensive? zdump takes 0.14 seconds here for one timezone. Running "date" takes 0.003= =20 (and it parses /etc/localtime). =2D-=20 =A0 Thiago Macieira =A0- =A0thiago (AT) macieira.info - thiago (AT) kde.org =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint: =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358 --nextPart2505995.7tdgLOEQ22 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGDmVLM/XwBW70U1gRAlvxAJ9y/YkWSwiTjcm1aRsh7nU7/42cNgCgp0Oj IQOSj17gIli1+lcLEZ1uH6w= =pTEx -----END PGP SIGNATURE----- --nextPart2505995.7tdgLOEQ22--