polled input related crash

BlitzMax Forums/BlitzMax Programming/polled input related crash

Ninjacrat(Posted 2007) [#1]
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



impixi(Posted 2007) [#2]
Confimed on my Windows XP system: the first example hangs, the second does not.


TaskMaster(Posted 2007) [#3]
What do you mean by "hangs"? You didn't make anyway to exit, so how do you know it is hung?


impixi(Posted 2007) [#4]
'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.


TaskMaster(Posted 2007) [#5]
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.


Vlad(Posted 2007) [#6]
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.


Ninjacrat(Posted 2007) [#7]
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.


marksibly(Posted 2007) [#8]
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.