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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to