Re: NSRunLoop behavior
Re: NSRunLoop behavior
- Subject: Re: NSRunLoop behavior
- From: Keary Suska <email@hidden>
- Date: Wed, 22 Sep 2010 08:33:38 -0600
On Sep 21, 2010, at 8:30 PM, Rafael Cerioli wrote:
> Ok, thank you for your answer.
>
> So, you are telling me that [self performSelector:@selector(waitUntilReady) withObject:nil afterDelay:1] is an input source ? What exactly is the input source, my selector or the timer that when fired, will call my selector ? I thought sources were like timers and port and stuff like that, and they were waking up the run loop, which is notifying the observers ?
-performSelector methods may be more like NSTimer objects, which aren't input sources per se, but still must be fully processed before a run loop will exit/return. I am not sure how run loop observers are notified in these cases (I assume same as timers).
Talking about observers, run loop observers are not input sources. Unless you specifically mean implementations of CFRunLoopObserver, using the term will confuse the issue.
> Another question : say you have two sources (or observers?). The first one to be processed calls a [[NSRunLoop currentRunLoop] runUntilDate:someDate]. Will the second one be processed as the first one never exits ? Will the first one be processed recursively (no...) ?
Generally, you should not be futzing with the run loop unless it is your own thread and/or you know what you are doing. Run loops are documented in the "Threading Programming Guide"--if you haven't read that thoroughly, you need to do so before messing with run loops. Also reading the NSRunLoop API docs, which indicate that you cannot rely that the main run loop will return at all, as the system may attach input sources as part of its operation. That being said, run loop operations are synchronous, and you likely need to re-assess your entire approach.
> On 2010-09-21, at 9:54 AM, Keary Suska wrote:
>
>> On Sep 21, 2010, at 5:55 AM, Rafael Cerioli wrote:
>>
>>> Hi,
>>>
>>> I'm trying to understand how run loops work. I've written this useless piece of code and I'm not sure why "success" does not show up...
>>> What happens is that waitUntilReady never terminates, because it seems that the runUntilDate in myButtonAction never ends as well.
>>
>> Yes, as that is what your code is doing.
>>
>>> My theory would be that calling a runUntilDate from myButtonAction (myButtonAction is started by a run loop observer) will just prevent other sources and observers in the *current* run loop's loop (or run loop's run ??) to be processed until myButtonAction terminates.
>>
>> No--there is no "prevention" whatsoever. -runUntilDate: tells the current runloop *specifically* to process all input sources, and to not exit until all sources are processed *and* the specified expiration date has been reached.
>>
>>> So, waitUntilReady's call to runUntilDate would prevent the end of myButtonAction's current run loop's loop.
>>>
>>> Does someone have more info about that ?
>>>
>>> - (void) myButtonAction {
>>> // A button event has been sent, waking up the run loop and calling that method
>>>
>>> // this will be called in 1 second
>>> [self performSelector:@selector(waitUntilReady) withObject:nil afterDelay:1];
>>
>> This is an input source, so the runloop will not exit until the method exits.
>>
>>> // process the current run loop during 10 seconds :
>>> [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:10]];
>>
>> Which never happens, as you never get to this line, because the method cannot exit.
>>
>>> [self setReady:YES];
>>> }
>>>
>>> - (void) waitUntilReady {
>>>
>>> while(![self isReady]) {
>>> // this should just process the run loop once :
>>> [[NSRunLoop currentRunLoop] runUntilDate:[NSDate date]];
>>> }
>>>
>>> NSLog(@"success!");
>>> }
>>
>> HTH,
>>
>> Keary Suska
>> Esoteritech, Inc.
>> "Demystifying technology for your home or business"
>>
>
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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