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: James Bucanek <email@hidden>
- Date: Mon, 19 Jun 2006 11:14:07 -0700
Chris Kane wrote on Monday, June 19, 2006:
>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.
Thanks for the additional details. I can see where this can get tricky, but I don't think my code is going to get into trouble. My timers don't run off and do anything exotic like put up modal dialogs, and the only events that would request my daemon to terminate would be a DO message or a distributed notification; both of which I assume *have* to be implemented as NSPorts attached to the main run loop.
Nevertheless, I think I'll add my own NSPort to the run loop anyway. That way I can send it a message via NSPortMessage and I should be 100% absolutely garenteed that the run loop gets at least one message, and one pass through the while(isRunning) loop, when I want to terminate. And as an added bonus, I can have an NSTimer kill the process too!
>> 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.
Good point, and after a little experimentation I see that performSelector:... (like NSTimer) doesn't go through the NSPort mechanism either.
--
James Bucanek
_______________________________________________
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