polled input related crash
BlitzMax Forums/BlitzMax Programming/polled input related crash
| ||
If you have a loop that Flips but doesn't have at least one polled input command then the program seems to hang after a few seconds. On my machine the first program hangs, the second works. Graphics 640, 480 Repeat Cls DrawLine Rand(640),Rand(480),Rand(640),Rand(480) Flip Forever Graphics 640, 480 Repeat Cls DrawLine Rand(640),Rand(480),Rand(640),Rand(480) Flip KeyHit(KEY_SPACE) Forever |
| ||
Confimed on my Windows XP system: the first example hangs, the second does not. |
| ||
What do you mean by "hangs"? You didn't make anyway to exit, so how do you know it is hung? |
| ||
'Hangs' in this context means the program stops responding, stops exectuting. The window cannot be moved around on the desktop. The second example does not exhibit these problems. |
| ||
It is probably because it is a tight loop and you do not have any functions to return timeslices back to the OS. That KeyHit() function probably returns time to the OS. You could also use the PollSystem() function. I vote not a bug, but a flaw in the program. |
| ||
Confirmed first sample hangs. But usually Repeat/Forever not uses. "Repeat/Until AppTerminate()" or "While not AppTerminate()/Wend" is better practice and AppTerminate is polls system input. |
| ||
You know, this is the first bug report forum where I get told off for reporting bugs. :) TaskMaster: It's not just a matter of returning time to the OS. Try putting a Delay() in there. It still hangs. Vlad: I know perfectly well how to work around it. But since it is a bug, I figured I should report it. |
| ||
Hi, The issue is that for windows gui apps to 'run', apps have to continually check with windows to see if any events have occured. This is when Windows gets to update the app's GUI etc - this is what PollSystem/WaitSystem effectively achieve. This is definitely not a 'free' operation though, so you don't want to be doing it too often - eg: every statement or even per-loop. So to 'fix' this bug requires the addition of a 'hidden' PollSystem somewhere. But where? Flip is the likely candidate as it is likely to be time consuming itself, however this could cause subtle problems. PollSystem can also cause events to be emitted via event hooks. If I start sprinkling Max modules with 'hidden' PollSystem's, there is a chance event hooks could fire at inconvenient times - eg: while inside an event hook which is painting/flipping, which could lead to recursion issues... Currently, Max assumes your app is running in either 'polled' or in 'event driven' mode - although users have mixed the 2 with varying degrees of success... The idea here was that in polled apps, users wouldn't have to worry about PollSystem - it would be automatically handled whenever user input is queried (KeyDown, AppTerminate etc). Event drivens apps on the other hand would get full control of when PollSystem occured, via PollSystem, WaitSystem, PollEvent or WaitEvent - and I like this degree of certainty. Frankly, I think the program is correct - your app isn't asking for any input, so none is given! Fudging a PollSystem in somewhere would likely have more negative consequences than the positive of allowing a non-real-world demo to run. Oh, and a PollSystem after the flip will fix it. |