On 01/11/11 12:51, Michael Van Canneyt wrote:
On Tue, 1 Nov 2011, Henry Vermaak wrote:
If you don't do this, daemons that were started before e.g. a daylight
savings update will report the wrong time after the update. Rather
solve this correctly than take short cuts because you want to keep the
time functions "fast". Someone can always add performance timing
helpers that use the correct functions on various OSes.
The problem with that is that a LOT of existing code contains many calls
to Now() and Date(), because these calls are very cheap on Windows. If
all these calls will suddenly cause a stat() of /etc/localtime, that's
simply not acceptable, since that will cause a noticeable error in your
reported time, as disk access is very slow and dependent on system load.
This is just speculation. There will always be an error in the reported
time, these calls are not atomic. It would be slower doing a stat, yes,
but saying that the error will be "noticeable" I will leave for you to
prove.
Also, how cheap is this on Windows? Presumably they will also have to
deal with potential system services running while updates fix daylight
saving time changes? If they don't use shared memory for this, I'd
wager that it's just as slow as libc localtime.
I don't think the definition of "acceptable" for the RTL should be "may
be wrong in corner cases, as long as it's fast". I'm sure you'd agree.
Henry
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
