Re: Inserting a task into the run loop
Re: Inserting a task into the run loop
- Subject: Re: Inserting a task into the run loop
- From: "Frank D. Engel, Jr." <email@hidden>
- Date: Thu, 26 Mar 2015 19:31:55 -0400
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 <email@hidden> wrote:
On 23 Mar 2015, at 12:47 pm, Graham Cox <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden