Re: NSRunLoop run semantics
Re: NSRunLoop run semantics
- Subject: Re: NSRunLoop run semantics
- From: "Roman Kishchenko" <email@hidden>
- Date: Tue, 9 Sep 2008 20:59:46 -0400
Chris, Bill, thanks for your replies.
My question was more about seeming contradiction between method description
("if no input sources or timers are attached to the run loop, this method
exits immediately") and behavior I observed (nothing is attached to the loop
by my application, yet, it does not exit immediately).
I have also tested runUtilDate: and runMode:beforeDate: and they also block
(until specified date) with no input sources registered by my simple tester
application. So, assuming method descriptions are correct, some input source
must have been registered by the Cocoa framework and is preventing runXXX
methods from returning immediately...
So, just to clarify, I should NOT assume that the run loop of the thread
that my application created processes only input sources attached by my
application? I.e. the Cocoa framework may also schedule some
application-unrelated tasks to be done on that thread? It would seem a
little odd... since I would have assumed that only application tasks are
performed on the thread spawned by the application, provided there are no
loop object leaks and such.
Thanks,
Roman Kishchenko
On Mon, Sep 8, 2008 at 7:39 PM, Chris Kane <email@hidden> wrote:
> On Sep 7, 2008, at 9:33, Roman Kishchenko wrote:
>
>> Hi,
>> I am new to Cocoa and have been experimenting with NSRunLoop. I would
>> appreciate clarification about 'run' method semantics. The documentation
>> states that:
>>
>> "If no input sources or timers are attached to the run loop, this method
>> exits immediately"
>>
>> Yet, in my thread example below, the 'run' invocation blocks and does not
>> exit. MyThread is a simple NSThread subclass. No custom input sources or
>> timers are registered with the run loop. Unless I misunderstand the
>> documentation or there are some 'hidden' input sources or timers are
>> registered with the run loop, I would expect 'run' to exist immediately.
>> Would much appreciate help with sorting this out!
>>
>> Thanks,
>> Roman Kishchenko
>>
>> @implementation MyThread
>>
>> - (void)main {
>> NSLog(@"++ start");
>> NSRunLoop *loop = [NSRunLoop currentRunLoop];
>> [loop run];
>> NSLog(@"++ finish");
>> }
>>
>> @end
>> _______________________________________________
>>
>
>
> This has come up before several times on this list over the years, so there
> are a few answers already in the archives. But I have an idea for a new way
> to explain it.
>
> The documentation is correct. However, it's trying to warn you that the
> method *can* return, not explain how to get it to return.
>
> The mistake people make is in assuming that they control the contents of a
> run loop (or even a run loop mode). However, the run loop is a global
> object, accessible to all code run on that thread (and perhaps other threads
> if you squirrel away a copy of the pointer somewhere). In particular, all
> frameworks that you call into, directly or indirectly, may access it and do
> things to it, including putting things in it.
>
> I think you are intuiting exactly this when you mention "custom" and
> "hidden" input sources.
>
> Try the -run...BeforeDate: method in a conditional loop if you want block
> in the run loop most of the time, but want to bail under some conditions
> (which would then be the test of the loop).
>
>
> Chris Kane
> Cocoa Frameworks, Apple
>
>
_______________________________________________
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