Re: NSRunLoop (sometimes) runs away

FROM : Chris Kane
DATE : Mon Dec 02 14:25:01 2002

On Saturday, October 26, 2002, at 05:33 PM, Tom Harrington wrote:
> I have a project which includes a faceless helper tool that needs to
> have a run loop.  Since the loop's not going to be run automatically,
> I used this:
>
>     NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
>     ...later ...
>     [runLoop run];
>
> This worked great for me, and for all of my beta testers.
>
> When the software got out into the field I got some bug reports that
> suggested the helper tool was not completing its run.  After some
> research, I found that in these cases, the [runLoop run] line
> basically spun off into the ether somewhere and never returned.  This
> after executing the same sequence of instructions as on other Macs
> where it worked normally.
> [...]
>
> I've worked around it by what seems a fairly crufty workaround in
> which I repeatedly call -[NSRunLoop runUntilDate], while also checking
> to see if I should keep making these calls.  This has fixed things on
> the affected systems, but I still have no idea why the original was a
> problem.  Presumably some other kind of data source became attached to
> the run loop, but why would the same sequence of steps lead to that
> situation on some Macs but not on others?



You're depending on the "-run returns when the run loop has no more
input sources" semantic.  In practice, it is impractical (or,
impossible) to rely on this "will quit" semantic, because you don't
know the set of all input sources that are in the run loop -- code that
you execute (or gets executed) in a library, say, can add run loop
sources of its own to the run loop, and there's no way for you to know
about those.  Plus, whether or not a chunk of code adds a source to the
run loop may change from release to release, and we do not consider
this a compatibility failure.  An historical example from years ago was
that executing NSLog() would add a run loop source to the run loop as a
side effect of some methods that NSLog() used.  So if the code went
down a path where some advisory or warning log was emitted, the -run
method's behavior appeared to change.  [And of course, I don't mean to
imply that NSLog() will no longer ever do this -- it may again in the
future, as may any library function/method/implicit initialization/etc.]

On the other hand, you have to know about this behavior of -run in
order to anticipate that it MAY return, which is why it is documented,
and you may want to do something in the code after it returns.

The -run method is a convenience method for running forever.  If you
don't want to run forever, you should use one of the other methods, as
you are doing with -runUntilDate: and loop yourself.  -run is just a
convenience method with such a loop.

I believe there are previous discussions of this, as well, in the
mailing list archives, for anybody wanting additional information.


Chris Kane
Cocoa Frameworks, Apple