On 18 Nov 2010, at 15:10, lorenzo7...@gmail.com wrote:
> Thanks everyone for all the replies. I've read through the docs again (its
> been years since I first set this up) and think I have a better understanding
> of how timers should work. I see now that the timer will fire once the
> comput
Thanks everyone for all the replies. I've read through the docs again (its
been years since I first set this up) and think I have a better
understanding of how timers should work. I see now that the timer will fire
once the computer is awakened from sleep, but it does take some time, maybe
On Nov 17, 2010, at 2:12 PM, Kyle Sluder wrote:
> On Wed, Nov 17, 2010 at 2:07 PM, Dave DeLong wrote:
> Here's what I got from that documentation:
>
> - An NSTimer is a run loop source.
>
> Ah, I think this is where my brain went all funny, because the NSRunLoop
> documentation mentions multipl
On Wed, Nov 17, 2010 at 2:07 PM, Dave DeLong wrote:
> Here's what I got from that documentation:
>
> - An NSTimer is a run loop source.
>
Ah, I think this is where my brain went all funny, because the NSRunLoop
documentation mentions multiple times that "A timer is not considered an
input source
Here's what I got from that documentation:
- An NSTimer is a run loop source.
- NSRunLoop monitors its sources for events, provided that the run loop is
running in the mode that the source is scheduled in.
- If the run loop is processing an event from a different source and a timer
fires, then
On 17 Nov 2010, at 1:54 PM, Kyle Sluder wrote:
> Okay, that's two people who have corrected me on this now. What am I
> misinterpreting about this documentation:
>
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html
Whi
On Wed, Nov 17, 2010 at 1:54 PM, Kyle Sluder wrote:
> On Wed, Nov 17, 2010 at 1:54 PM, Greg Parker wrote:
>
>> On Nov 17, 2010, at 1:35 PM, Kyle Sluder wrote:
>> > That's not how timers work. They only fire if something wakes the runloop
>> > after their time has expired. Usually this is an event
Timers will cause a runloop to fire (depending on run mode of course)
without any other source having to fire.
#import
@interface TimerTest : NSObject
@end
@implementation TimerTest
- (void)runTest {
NSLog(@"Test Thread Running");
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] in
On Wed, Nov 17, 2010 at 1:54 PM, Greg Parker wrote:
> On Nov 17, 2010, at 1:35 PM, Kyle Sluder wrote:
> > That's not how timers work. They only fire if something wakes the runloop
> > after their time has expired. Usually this is an event.
>
> Not true. A timer may fire some time after its fire d
On Nov 17, 2010, at 1:35 PM, Kyle Sluder wrote:
> That's not how timers work. They only fire if something wakes the runloop
> after their time has expired. Usually this is an event.
Not true. A timer may fire some time after its fire date for any number of
reasons, but "no event to wake the run l
On Wed, Nov 17, 2010 at 12:41 PM, Lorenzo Thurman wrote:
> I use two NSTimers in my app. One runs a "mini" data fetch at regular
> intervals. I use another to run a "full" data fetch every 4 hours. The
> problem I'm running into is that while the mini fetch runs as scheduled,
> the
> full fetch ne
11 matches
Mail list logo
