The compiler is likely optimizing a loop with no statements in its
body. Possibly, a bug, even?
However, yes, this is not a good way to handle state across
threads. It busy-waits the CPU, eating tons and tons of CPU
spinning madly waiting for something to be done -- and slowing down
the task that is running in the other thread (and everything else
on the system). If this is a Cocoa app and you are busy waiting
from the main thread, you have also rendered the application
completely unresponsive.
For non-Cocoa apps, use a lock.
For Cocoa, use one of the methods that performs a selector (a
method) on the main thread to pass notification between the threads.
Thanks Bill,
In practice, the loop should end almost immediately, because the task
in the other thread will check a variable that will cause it to exit,
so the busy-wait cycle is normally extremely short-lived. This was
just my rather simplistic way of making sure the secondary thread
exits before the window closes. But you're probably right that
compiler optimization is causing the release build to fail.
I'll implement things more properly the way you suggest. Many
thanks for the pointers, and thanks to Matt Neuburg for the link to
the documentation on Cocoa Locks.
António
-----------------------------------------
Forgiveness is the perfume
that the trampled flower casts
upon the heel that crushes it.
-----------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
