I think you might be able to use this:
[object performSelectorOnMainThread:(SEL)aSelector
withObject:nil
waitUntilDone:NO];
If I am interpreting the behavior of that call correctly, you would need
to call that once to get it started, then at the end of the method that
aSelector points to each time it runs until it is time to stop (then
just stop calling that).
On 3/23/2015 01:49, Roland King wrote:
On 23 Mar 2015, at 13:05, Graham Cox <graham....@bigpond.com> wrote:
On 23 Mar 2015, at 12:47 pm, Graham Cox <graham....@bigpond.com> wrote:
But what actual form would a task take that said "loop as many times as necessary
until there's no more to do, then finish"?
Just to clarify, as re-reading this it isn't clear what I really mean:
I mean a task that will loop on each turn of the run loop until done, then
finish. Seems to me there isn't really anything that quite fits that - an
NSOperation fires once, so I'd need to keep creating these and rescheduling
them. Maybe that's OK, performance wise? Alternatively a timer can be made to
fire once per run loop, but never stops. Maybe a thread with a lock really is
the best approach here, especially as it punts the simulation on to a second
processor so it can run as fast as possible as long as it needs to. The hassle
there is messaging the main thread for UI updates and all the usual
multi-threaded gotchas.
I've had lots of helpful suggestions (thanks!), but the best way forward is
still not that obvious.
—Graham
Why not just enqueue a block on the main queue, if you want it to be on the
main thread. if you determine you have more work to do, ie another iteration is
required, you enqueue another one asynchronously at the end. A quick test seems
to indicate that the main loop goes around and services all the other things it
has to do before dequeueing the next block off the main queue, thus keeping the
UI active.
Personally I’d probably make a separate queue just for the simulation and make
all changes to the model by posting blocks to that queue, keep the entire model
running away from the UI, then post changes back the other way to update the UI
because I’m pretty sure sooner or later I’d run into performance issues running
the simulation on the main thread.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/fde101%40fjrhome.net
This email sent to fde...@fjrhome.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
