Re: NSRunloop performSelector needs CFRunLoopWakeUp ?
Re: NSRunloop performSelector needs CFRunLoopWakeUp ?
- Subject: Re: NSRunloop performSelector needs CFRunLoopWakeUp ?
- From: "Stephen J. Butler" <email@hidden>
- Date: Sat, 24 Jan 2009 15:17:52 -0600
On Sat, Jan 24, 2009 at 2:42 PM, David Hoerl <email@hidden> wrote:
> I have a few hundred tasks to handle, and am using NSRunLoop's
> performSelector to get the scheduled:
>
> -(void)nextTask:(SEL)sel
> {
> [[NSRunLoop mainRunLoop] performSelector:sel target:self argument:nil
> order:0
> modes:[NSArray arrayWithObject:NSDefaultRunLoopMode]];
>
> CFRunLoopRef crf = [[NSRunLoop mainRunLoop] getCFRunLoop];
> CFRunLoopWakeUp(crf);
>
> }
[snip]
> What seems really odd is that I have used this technique in the past without
> issue. The current app is single threaded.
I'm kind of confused as to how 10.5 extended NSRunLoop. On the one
hand, there's this +[NSRunLoop mainRunLoop] method that seems to imply
you can play with the main runloop from other threads. On the other,
the documentation is still littered with warnings that NSRunLoop is
not thread safe. Talk about mixed messages!
Also, -[NSObject
performSelectorOnMainThread:withObject:waitUntilDone:] now uses
NSRunLoopCommonModes -- instead of NSRunLoopDefaultModes -- when it
places the selector in the runloop. And NSRunLoopCommonModes is a new
constant in 10.5.
So I guess my question is what happens when you change your code to this:
-(void)nextTask:(SEL)sel
{
[self performSelectorOnMainThread:sel withObject:nil waitUntilDone:NO];
}
_______________________________________________
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