wait 0 with messages

[makeshyft]

Hi Livecoders,

Can someone please help me understand why I have to use "wait 0 with messages" to stop the engine from locking up the UI? when doing a tight repeat loop....... even when I lock the screen it still ends up " non responsive" until the handler finishes. I just don't get why the engine is ahead of itself....lol

My goal is to understand this engine inside and out.

Thanks ahead of time.

[FourthWorld]

This was a Mac-specific anomaly due to some of the interactions between LiveCode and Cocoa. This has been fixed for v6.7 and 7.0, both available for testing now.

[makeshyft]

Excellent.......I have to process a lot of things in tight loops, so I am always running into using this, and using it without knowing why i am using it makes me crazy. Thanks Richard.

Will check out those builds and see if indeed it still happens.

Cheers

[makeshyft]

I am actually on Windows 7 , and I just tested 6.7 dp8 and it still locks up the UI in a tight loop.

[FourthWorld]

Hmmmm...it might be a bug, or it might be a performance optimization in which LC is just running too fast for Windows' redraw mechanism to keep up with.

But in the latter case, where performance is critical it's probably better to just lock screen/update UI/unlock screen to show the update/lock screen again anyway, so maybe this should be filed as a bug report to see how the engine team explains it.

[makeshyft]

Now that I think about it ..... That is how it was explained before, having to do with exactly what you said the redraw mechanism..... I do lock my screen, but it still displays "not responding" in the window..... I will file this ..... because maybe it would be easy to add a routine that prevents this from happening. "wait 0 with messages" adds a lot of milliseconds ..... and I am running through 100,000 user arrays.

I do LOVE the idea of the engine doing something TOO FAST...lol. Thanks Richard.

[FourthWorld]

Now that I think about it ..... That is how it was explained before, having to do with exactly what you said the redraw mechanism..... I do lock my screen, but it still displays "not responding" in the window..... I will file this ....

Ah, wait a minute - "not responding" might be related to simple redraw actions, but normally we'd expect to see that with applications that have died, or for some reason aren't polling the OS frequently enough for events.

Still sounds like a bug, but possibly unrelated to redraw. Can you describe what the code is doing when you get that error notification?

Please keep us posted with what the team says. If you don't mind, it would be helpful if you could post the report number here after you submit it so interested members can follow the progress on this issue.

[makeshyft]

http://quality.runrev.com/show_bug.cgi?id=13142

[[-hh]]

..........

[dunbarx]

Hermann.

Can you explain what you mean? I read: "wait 0 with messages" to be equivalent to: "wait 0 ticks with messages"

The default keyword being "ticks".

How does the explicit inclusion of "milliseconds" matter, if one is waiting for "0" of them. In other words, if one is not really waiting, does it matter for how long? Does one of those "keywords" actually transpire? Because at least one would have to, in order to make a difference.

Craig

[[-hh]]

..........

[makeshyft]

its a feature that the windows process locks up during tight loops? the bug report was not about the merits of waiting 0 but rather a non responsive window.

...... waiting 0 with messages does add time to how long a handle takes, so for whatever reason its not really waiting 0.

I use milliseconds to count. I find it accurate enough for anything I need at this point timing wise.

Cheers dudes

[dunbarx]

waiting 0 with messages does add time to how long a handle takes, so for whatever reason its not really waiting 0.

For sure. The line of code itself has to be executed, after all, and that is enough to solve a world of issues. I was wondering if it mattered how long you did not wait, a tick or a mS.

Craig

[FourthWorld]

"wait 0 with messages" adds time to long tasks because it's surrendering time to the OS and internal event loops. Whether you wait "0 milliseconds" or "0 seconds" it's still 0, which is to say it immediately gives a slice of CPU time over to the event loops.

[[-hh]]

..........