path: root/setup_native/
diff options
authorJan-Marek Glogowski <>2017-07-19 15:48:39 +0200
committerJan-Marek Glogowski <>2017-07-20 17:55:10 +0200
commit37436815970b14f8940fc0c547862452a2dc3e1e (patch)
tree65d4c7bfa7c9c4695e9cd412f378ff172567f9b9 /setup_native/
parentc73ce1dabd3cec36a3c3a4a5fcd87aef3a8bb593 (diff)
tdf#109123 WIN Run instant timerout with low priority
This busy-lock happens, because user messages have a higher priority then some system messages. What happens: 1. The main system loop picks up the LO scheduler 2. The idle worker (IW) is started 3. IW checks using AnyInput( VCL_INPUT_ANY ) for system events 4. A system event is found 5. The LO scheduler gets posted again 6. The main system loop picks up the LO scheduler instead of the system message => goto 2 Normally it's suggested to use WM_TIMER in this case, as these messages are supposed to have the lowest priority. But this doesn't work, if you use PostMessage to generate them and SetTimer doesn't accept a 0ms timeout. At least PeakMessage also picks up the WM_TIMER message before the system message, probably because PostMessage is somehow related to the threads queue - who knows. In the end this implements a manual, low priority event, which is checked at the end of the ImplSalYield function. It just runs, if there is nothing else to do. We still have to emit the timer callback event, as ImplSalYield may wait in GetMessage, but wParam now indicates, if it's a wakeup and can be ignored. We use the same event, so it's easier to filter. Thanks to Mike Kaganski for the missing information and ideas for the final implementation. Change-Id: Ib8e4f214ab8d3731d5594d68f38f46982c2eb36d Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Jan-Marek Glogowski <>
Diffstat (limited to 'setup_native/')
0 files changed, 0 insertions, 0 deletions