Am 03.11.2011 17:38, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912&view=markup
(line 277ff)
That code doesn't make sense, without additional information :-(
283 do
284 {
285 SystemTime.HighPart = SharedUserData->SystemTime.High1Time;
286 SystemTime.LowPart = SharedUserData->SystemTime.LowPart;
287 }
288 while (SystemTime.HighPart != SharedUserData->SystemTime.High2Time);
As long as no functions are involved, the loop copies the same
information into SystemTime, over and over again.
As Vinzent wrote, the SystemTime field is considered volatile (take a
look at %fpcdir%\rtl\nativent\ndk\ketypes.inc; I have kept the
"volatile" keywords as comments when translating that _KUSER_SHARED_DATA
struct). This code is also found throughout ReactOS (and I expect
Windows as well) when the time is fetched inside one of the operating
system components. I've basically copied this code for the GetLocalTime
implementation of my NativeNT port and it definitely works and does not
loop till the end of eternity :)
On POSIX
platforms gettimeofday and localtime_r is used instead (Delphi XE). All
this handling makes Now() quite expensive, so that (a future) FPC should
provide cheaper means for getting time stamps.
The problem with localtime_r itself is that it's implemented in LibC
which must be avoided for the non-LibC-RTL. So FPC definitely must
provide an implementation of its own for this.
Then something like WinAPI SystemTimeToTzSpecificLocalTime has to be
implemented. That function can be used for every platform, provided that
the SystemTime is stored in an platform independent way.
Something like this, yes.
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
