17 ms·

Ah that makes sense. Figured it had something to do with the message pump (the mouse move is a classic tipoff of that pattern). Yeah those message semaphore f

Ah that makes sense. Figured it had something to do with the message pump (the mouse move is a classic tipoff of that pattern). Yeah those message semaphore functions are seriously neat. But they have a few sharp edges around when they are not listening (race condition usually). I had something similar with pulseevent a few years ago. Pulsing while processing would sometimes miss the event because there was nothing waiting it was busy doing things, and would loop around to wait again but not do anything because it 'ignored' the pulse. In that example you posted it depends on when the 'extra' message shows up. Depending if it is before or after the peek it will sometimes work (race condition).

ComputerGuru 5y ago
PeekMessage and PulseEvent are convenience functions that should have never been written. I intentionally excluded PulseEvent from my posix port of WaitForMultipleObjects because it is inherently racy: https://github.com/NeoSmart/PEvents https://github.com/NeoSmart/PEvents (It can be enabled via a compile-time define because my OCD kept me from shipping an incomplete port.)
- sumtechguy 5y ago
  For me luckily the guy who had wrote the whole thing had wrapped the set and wait part. So I could put in a lock in there to mitigate the race condition. I also yanked out using the windows message passing parts and used a shared memory space (memory was tight and the timing was unfortunately critical, but I could mitigate it by blocking if the memory space was full, not great but it worked). I have used peekmessage many times but I usually use it with some sort of sleep condition. It gives a weird kind of 'janky' feel to the application but in some cases it works fine. These days I would use a proper message passing queue system and a thread instead of trying to hijack the windows ones. It is the 'wait' functions that are the culprit. They basically only wait once you call them. Anything outside of that, your problem and you end up wrapping the things in locks to get it to work right as the 'wait function' is basically a shared resource in windows world.

ComputerGuru 5y ago

PeekMessage and PulseEvent are convenience functions that should have never been written. I intentionally excluded PulseEvent from my posix port of WaitForMultipleObjects because it is inherently racy: https://github.com/NeoSmart/PEvents https://github.com/NeoSmart/PEvents (It can be enabled via a compile-time define because my OCD kept me from shipping an incomplete port.)

sumtechguy 5y ago
For me luckily the guy who had wrote the whole thing had wrapped the set and wait part. So I could put in a lock in there to mitigate the race condition. I also yanked out using the windows message passing parts and used a shared memory space (memory was tight and the timing was unfortunately critical, but I could mitigate it by blocking if the memory space was full, not great but it worked). I have used peekmessage many times but I usually use it with some sort of sleep condition. It gives a weird kind of 'janky' feel to the application but in some cases it works fine. These days I would use a proper message passing queue system and a thread instead of trying to hijack the windows ones. It is the 'wait' functions that are the culprit. They basically only wait once you call them. Anything outside of that, your problem and you end up wrapping the things in locks to get it to work right as the 'wait function' is basically a shared resource in windows world.