Re: NSRunLoop run semantics
Re: NSRunLoop run semantics
- Subject: Re: NSRunLoop run semantics
- From: Chris Kane <email@hidden>
- Date: Tue, 9 Sep 2008 18:41:32 -0700
On Sep 9, 2008, at 17:59, Roman Kishchenko wrote:
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?
Essentially correct. [But you should also not assume that some
framework WILL install something in a run loop.] It would be
particularly true for the main thread, that frameworks may install
things in the main run loop, but it's possible with other threads as
well.
It boils down to: frameworks are clients of the run loops, just like
the app itself.
Chris Kane
Cocoa Frameworks, Apple
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