Mailing lists / fpc-pascal / 2022-04
7 messages · 5 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Hi Michael,
Under Linux a RTLEventWaitFor(e,1) usually waits at most 1ms. But under Windows it usually waits at least 15ms. It seems to round to nearest 1/64 of a second.
Googling this lead me to question the sanity of some bloggers.
Has anyone an idea if this is normal on Windows and if there is an alternative?
Mattias
RTLEventWaitFor uses WaitForSingleObject internally.
According to this:
https://docs.microsoft.com/en-gb/windows/win32/sync/wait-functions
The system clock (and not some high-performance counter) is used to determine resolution of the timeout. You could call timeGetDevCaps to check the resolution.
Michael.
On Tue, 5 Apr 2022 10:23:45 +0200 (CEST)
Michael Van Canneyt via fpc-pascal
It gives min 1, max 1000000.
I tried setting with timeBeginPeriod without effect.
Mattias
Long shot...
From the docs:
Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10 and Windows Server 2016: The dwMilliseconds value does not include time spent in low-power states. For example, the timeout does not keep counting down while the computer is asleep.
Maybe check power mode settings ?
Michael.
On Tue, 5 Apr 2022 10:23:45 +0200 (CEST) Michael Van Canneyt via fpc-pascal It gives min…
Mattias Gaertner via fpc-pascal schrieb
am Di., 5. Apr. 2022, 10:36:
Current Windows doesn't respect timeBeginPeriod like it used to (we had a problem with that at work as well). In the end there's not much you can do. If the OS doesn't provide smaller timeouts then you're simply out of luck.
Regards,
Sven
Under Linux a RTLEventWaitFor(e,1) usually waits at most 1ms. But under Windows it…
As for the alternative bit.... Maybe
I have some code in components\fpdebug\fpdbgutil.pp (e.g, one side in TFpThreadWorkerItem.WaitForFinish) doing the following. (simplified version)
- Thread T1 => Worker: sets event when ready
- Thread T2 => Controller: waits for event. (But could easily be extended to just check the state, without waiting)
Both threads use a variable via InterlockedExchange.
- The variable starts with TWSTATE_RUNNING => T1 is busy
- When T1 finished, and T2 does not yet wait (See below): It sets TWSTATE_DONE
- When T2 needs the result:
~ if the state is TWSTATE_DONE then it never needs to call RtlEventWait ====> not calling RtlEventWait => no timeout needed at all ~ Otherwise it sets TWSTATE_WAIT_WORKER, and calls RtlEventWait (In this case no timeout either, as it waits until the event comes) ==> But instead of calling RtlEventWait it could return the state.
- When T1 finished, and T2 does wait (TWSTATE_WAIT_WORKER) then T1 sets the event to signal T2
Under Linux a RTLEventWaitFor(e,1) usually waits at most 1ms. But under Windows it…
Hello,
On Windows the timer resolution is 1/64, that's 15,6 ms. You can change it by using "NtSetTimerResolution" but it is system wide and other programs can fail or have strange behaviour. MS recommends to not change it, but some programs like Chrome do it for some chuncks of time.
You can check the 15.6 ms using a tight loop of GetTickCount.
Have a nice day.