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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
