Hi Folks,
I’ve always looked at a tight loop as needing to do something in the loop to give the app breathing room. Something like multiply 3 numbers …
However, in troubleshooting a UI update issue (NOT in a thread), I discovered that:
Do
// nothing
Loop Until Not OperationSetActive Or OperationErrWorks perfectly and doesn’t impart a tight loop CPU penalty as I expected.
Did I just get lucky, or are Xojo loops a bit smarter than me 
?
Loop boundaries allow for thread switches to occur (they do not guarantee one will occur - they just could occur).
So if you have other threads going they could run and you may not get a huge CPU penalty.
But put a loop like
while true
wendin the app open event before any other threads start up and you will get a CPU burner
Are you sure the flags are what you think they are? Is the loop executing at all?
It’s definitely executing or the long running process (which is in a thread, Norman) wouldn’t run.
I’m running Instruments on it to see what’s really happening.
Assuming that loop is in a thread, then you’d get even better performance by sleeping inside the loop.
This is incorrect and will burn even more cpu than the empty loop. Sleeping is still better than either.
In the main thread, you should forget tight loops in favor of timers.
Stop the code just before where you did the tight loop, and start a timer. Put the rest of the code after the tight loop in the timer Action.
That way you won’t burn the CPU and will not freeze the UI.
In a thread, well, you will consume CPU only as much as the thread priority allows…
That’s what I’ve always assumed, but the situation above proves otherwise regarding the main loop. That’s what has me curious.
Tight loops in the main thread very effectively freeze the UI. To me, that is unacceptable. And since App.DoEvents is evil in Xojo, better use a timer. It will use next to zero CPU, and is much better in tune with event programming.
I already told you way way way back when whats going on
IF you had a LOOP like that and NO THREADS it would just burn CPU
But because you DO have threads they may get switched to - perhaps a lot - and they’ll proceed
Stick a few debug logs in
One IN the body of the loop and then some in whatever code your threads execute
I understand all that and agree with you both. My point here is not in reference to best practices, or how it SHOULD work, just a comment about how this unexpected scenario has shown itself while tracking a different issue.
Sort of like how I discovered yesterday that I can run a Proto2000 EMD E6A on a 15" radius curve. I;d never do that in a real operational session (and it looks ridiculous), but it is interesting that a locomotive that long would not derail on a tight curve like that.
The trucks do swivel don’t they ?
Strikes me that should behave like moving a super long wind turbine blade around VERY tight curves
like this http://www.cnn.com/videos/world/2017/10/05/trailer-turning-scotland-wind-turbine-blade-sje-lon-orig.cnn
They do - to a point, but they still are tight since they are 3 axle trucks and luckily the center axle has a bit of side to side play. Looks silly with the body hanging over the inside of the curve. Definitely not “to scale”