[fpc-devel] Problem with Now() and time changed by ntpd

[Jonas Maebe]

Marco van de Voort wrote on Wed, 02 Nov 2011:

> In our previous episode, Jonas Maebe said:
>
>> Anyway: a function that reports the local time is simply
>> the wrong tool for the job if you need a "mostly" monotonic timer that
>> you can query at a high frequency. It may work (and apparently it does
>> for you), but instating a plugin architecture just to be able to keep
>> using it for that purpose is the wrong approach as far as I am
>> concerned.
>
> True, but as said a very common abuse.

Fine, and in most cases people probably won't notice the difference of  
an added fpstat call.

> Oh, and btw, I forgot, I update a
> clock on my app once a second too (which is not that strange for
> systems that run fullscreen).

The only use of displaying this is if it actually matches the real  
time rather than something that may or may not match it (and matching  
it most of the time is the best way to cause lots of irritation when  
it suddenly doesn't match it anymore).

> Note again that my apps are not in FPC, and could be easily changed. They are
> just meant as illustrations of very common use (and thus of the number of
> support issues you can expect when sb after a lot of debugging finds out
> that the system reacts differently, *JUST* like the issue that initiated
> this thread)

I don't expect many issues at all. Your application probably wouldn't  
suddenly start behaving very differently because of one added fpstat  
call per now() call either.

>> And even if it is eventually transformed into a pluggable API, fixing
>> it now does not require this plug-in architecture to exist, nor does
>> fixing it make it harder to transform it into a pluggable API
>> afterwards.
>
> That kind of quick and dirty mentality and pooh,poohing away sideeffects
> (like a noticably slower gettime) without a way to override it is exactly
> what I'm afraid of.

There is nothing dirty about this fix. It is a completely standard  
implementation for getting the local time on a Unix platform, and  
probably used by C libraries everywhere (I'm at least not aware of any  
C library firing up a separate thread to monitor changes to the  
timezone file).

Yes, the result slower, but it's also correct (as in "it makes sure  
that the actual local time is returned"). Just like all UTF-16 code in  
the RTL is slower than what Martin Schreiber would like, and we didn't  
change it to UCS-2 when he asked to do so for speed reasons.

It's a quick fix, but if it's not dirty that's a plus rather than a  
minus as far as I'm concerned.

>> It is related as far as I am concerned, because the above is how Now()
>> currently works on Unix and as far as I understand, you don't want it
>> to be fixed using a straightforward stat/update check because that may
>> reduce the performance/rate properties of that call.
>
> I meant that wrt compatibility, since such solution requires an audit of all
> gettime use,

It's the current implementation that requires an audit of all gettime  
use, because if people expect to always get the local time there then  
this assumption is wrong.

> Minimizing that is one of the things compatibility is about. More
> importantly, the various requirements don't bite eachother, except that a
> proper solution might require some more functionality in the core set (hence
> plugin route).

I disagree that a simple fpstat call is not a proper solution. There  
may well be solutions that introduce less perturbation, but the basic  
requirement of gettime/now is that it returns the local time and not  
that it is executes in the same amount of time as getting the time in  
a non-adjusted way.


Jonas

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.