On 05/04/2022 01:03, Mattias Gaertner via fpc-pascal wrote:
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.
Has anyone an idea if this is normal on Windows and if there is an
alternative?
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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
