Re: Secondary run loops?
Re: Secondary run loops?
- Subject: Re: Secondary run loops?
- From: Chris Suter <email@hidden>
- Date: Thu, 10 Aug 2006 14:50:29 +1000
On 10/08/2006, at 2:38 PM, email@hidden wrote:
On 10/08/2006, at 1:48 PM, Andrei Tchijov wrote:
calling
[[ NSRunLoop currentLoop ] runUntilDate: [ NSDate
dateWithTimeIntervalSinceNow: 1.0 ]]
in place of WaitNextEvent() might help
You should be aware that doing things this way might mean that
whatever you're doing could get interrupted for a time if the user
can do things that take a while. For example, many things process
their own events whilst the mouse is down. Or you might have an
application modal dialog that gets displayed which again processes
events outside of your control. You'd also obviously want to avoid
recursion. The other thing to be wary of with the approach is that
you need to process the run loop sufficiently fast that the user
interface still seems responsive; calling the method above every,
say, 10 loops might work well on your machine but not on a slower
machine.
Using a separate thread to do the work you need avoids these
problems, although is arguably more complicated to implement.
I want to try to do the most correct thing; however, I'm not sure
how to implement UI threads (I thought you couldn't do UI from a
thread):
You can't.
loop
do_something() <--- this is a thread
update_status(); <-- this is UI stuff
Is the whole loop put into a thread (so you have two levels of
threads)?
No.
Even if it is, I still don't know how to get the UI to refresh--
it seems that what ever I do doesn't show up (updating a text
view, progress bar, etc) until a Cocoa event loop gains control.
My main lack of understanding comes from how to loop and still get
the UI to refresh. Andrei's solution makes that happen (I'm used
to the recursion issues that you've brought up from my Carbon
programming days), but if there's a better way (or more Cocoa way),
I'd like to know it.
You start a new thread by calling -[NSThread
detachNewThreadSelector:toTarget:withObject:].
Make sure you create your own autorelease pool if you're going to be
allocating and releasing objects.
You keep all GUI stuff in the main thread.
There are two ways to do updates:
1. Start a periodic timer in your main thread and use a shared
variable to store progress information. You protect your shared
variables using @synchronized or NSLock objects if necessary (if it's
just a 32 bit integer storing progress that's not necessary).
2. or, use performSelectorOnMainThread:withObject:waitUntilDone: from
your thread.
When your worker thread is done use performSelectorOnMainThread:...
to report completion.
To abort, use a variable that you set in the main thread and check it
at opportune moments in your worker thread.
- Chris
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden