Re: Stopping an NSRunLoop OR getting NSDistributedNotificationCenter notifications
Re: Stopping an NSRunLoop OR getting NSDistributedNotificationCenter notifications
- Subject: Re: Stopping an NSRunLoop OR getting NSDistributedNotificationCenter notifications
- From: Chris Kane <email@hidden>
- Date: Mon, 19 Jun 2006 10:38:58 -0700
On Jun 19, 2006, at 10:08 AM, James Bucanek wrote:
OK, I clearly don't understand the difference between runUntilDate:
and runMode:beforeDate:. Re-reading the documentation again (slowly
and out loud), I get the picture that runUntilDate: runs the loop
repeatedly returning only after date has occurred. But
runMode:beforeDate: processes exactly one event and then returns.
Is that correct?
Roughly.
To prevent starvation of sources in some situations, the run loop may
need to process more than one event in a given cycle, then return.
But you can think of this in terms of "the run loop will return after
each time it does something" (except timers, or observers at the CF
level, and anything built on those facilities). The point being that
you can't count on "one and only one" source having been processed
(though you'd have to be going out of your way I think to do that).
Also, source which are processed by reentrant activations of the run
loop don't count as part of this "return after doing something"
business. For example, if a timer fires, and runs the run loop
during its callout, it may process any number of other "events/
sources", which won't cause the base activation to return when the
timer callout returns to the run loop.
If that's correct, then I can do this far more simply than I
thought. I don't even think I need anything as elaborate as you've
outlined, as the message that will be terminating the process will
always occur on the main thread (in response to a DO message or a
distributed notification). So I don't think I have any cross-thread
communications issues; the while(isRunning) loop that's running the
loop should cycle as soon as my -stopDaemon message returns.
Random thought: Your NSPort/NSPortMessage idea is excellent, but
wouldn’t' a performOnMainThread: message work just as well?
If performOnMainThread: is implemented via a run loop source, and not
a timer or observer or some direct hook into the run loop
implementation, then yes. However, you can't know how that's
implemented, and it may change from release to release. I can
definitely say that it's not implemented by sending a message to a
port in the target run loop in any releases.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
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