[wxhaskell-users] Timer results in lockup
I have an application using a timer with a 200ms interval. When I change the interval to 100ms, the application locks up. I assumed the problem was a callback was made before the previous callback was complete. So I added an MVar to protect against executing IO in parallel. With 200ms, the MVar code runs fine. But at 100mS it locks up. I tried to use putStrLn to prove that a try on MVar got a nothing and that the extra callback exited without any IO. However, I never saw any printing. But this could just be a problem of overlapping IO itself. What I was was callbacks that did not appear to overlap, followed by lockup. My assumption is the lockup happens before the callback can do a try on the MVar Does anyone know: - Will the timer callback if a previous callback is not complete? - Is there any known lockup from overlapping callbacks? - Is there a proper way to handling potential overlapping callbacks? As far as I can tell, the only mechanism I have other than synchronization techniques, is to manipulate the interval from the callback. - If the interval is lengthened and shortened, does the current time remain in tack? - If the time is shortened, would it trigger an immediate callback if the time is less than the current timer? - Or is the timer restarted with the interval changed? I am using the latest version of wxHaskell. Just built it yesterday and wrote my first app. Using 3.0.1 on Ubuntu 14 TLS. Mike -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] Timer results in lockup
I have an application using a timer with a 200ms interval. When I change the interval to 100ms, the application locks up. I assumed the problem was a callback was made before the previous callback was complete. So I added an MVar to protect against executing IO in parallel. With 200ms, the MVar code runs fine. But at 100mS it locks up. I tried to use putStrLn to prove that a try on MVar got a nothing and that the extra callback exited without any IO. However, I never saw any printing. But this could just be a problem of overlapping IO itself. What I was was callbacks that did not appear to overlap, followed by lockup. My assumption is the lockup happens before the callback can do a try on the MVar Does anyone know: - Will the timer callback if a previous callback is not complete? - Is there any known lockup from overlapping callbacks? - Is there a proper way to handling potential overlapping callbacks? As far as I can tell, the only mechanism I have other than synchronization techniques, is to manipulate the interval from the callback. - If the interval is lengthened and shortened, does the current time remain in tack? - If the time is shortened, would it trigger an immediate callback if the time is less than the current timer? - Or is the timer restarted with the interval changed? I am using the latest version of wxHaskell. Just built it yesterday and wrote my first app. Using 3.0.1 on Ubuntu 14 TLS. Mike -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
