On Friday 30 March 2007 18:07:51 Thiago Macieira wrote:
> David Jarvie wrote:
> >The only case where a significant amount of processing may be required
> > at initialisation is on those systems where the local time definition
> > file /etc/localtime is held as a copy of, rather than a link to, one of
> > the zoneinfo files.
>
> So you're saying that the only case of significant amount of processing is
> the default case?
>
> 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?

> 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?

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 session, and also cached between sessions 
(with suitable change monitoring). As Lubos observed 
(http://lists.kde.org/?l=kde-core-devel&m=115884044529385&w=2), it can lead 
to significant disc activity, although with code improvements (use of country 
codes) introduced since then it should generally be much improved by now 
except on Solaris.

2) On Solaris, there is a lot of file I/O required to create the list of time 
zones equivalent to zone.tab. This certainly needs to be cached between 
sessions, and shared between applications.

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. Creating the collection is a trivial step 
after this. The advantages of creating the KSystemTimeZone collection in the 
kded module and sharing it are:

- 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.

- 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.

- It may be easier to update the instances with new definitions should the 
zoneinfo files get updated.

So the overall advantage is not so clear for this function.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm