Re: creating multiple NSTimers
Re: creating multiple NSTimers
- Subject: Re: creating multiple NSTimers
- From: Thomas Davie <email@hidden>
- Date: Fri, 30 Sep 2011 08:29:03 +0100
On 30 Sep 2011, at 08:19, Conrad Shultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 9/29/11 10:50 PM, Greg Guerin wrote:
>> Gordon Apple wrote:
>>
>>> There must already be an array for the table, so just iterate
>>> the
>> array every
>>> minute or whatever (single repeating timer), compare the times to
>>> [NSDate date} and start or shut down whatever has not been
>>> started or shut
>> down. Much
>>> easier than trying to manage timers.
>>
>> You don't have to iterate the whole array, either. Sort it by
>> ascending order of turn-off time. Keep a current position (index).
>> If the time of day is less than the turn-off time of the device at
>> the current position, do nothing. If time of day >= turn-off time
>> of current position, then turn it off and advance position until
>> time of day is again less than the turn-off time of device at the
>> current position. Only needs one timer, and scales to as large an
>> array as you want to keep.
>
> I don't really see how this is superior to keeping the one timer per
> remote box.
>
> When the user updates a timer, one is forced to re-sort the array and
> reposition the index (under the above implementation).
Why would you need to resort? Just remove, and reinsert.
> One would also have to implement the scheme carefully, particularly if
> the shut-off code is offloaded onto separate threads, to avoid
> potential race conditions arising from a user changing a fire date in
> the middle of a shut-off sequence.
Careful locking required in multithreaded environment – unsurprising.
> And as Graham mentioned, polling is probably less CPU and power
> efficient than using timers anyway.
Who's suggesting polling - you simply have one timer set for the time at which the first of your actual timers goes off. When it goes off, you fire the first of your actual timers, and reschedule your "when do other timers go off" timer.
> Am I missing something conceptually here? Why are people pushing for
> the single timer model? Is there some hidden complexity in a
> multi-timer approach that I'm not seeing?
I implemented the single timer model yesterday, but I have to admit, the reason was because I'm targeting GNUstep, and when I stared at their source I discovered that they simply itterate through *all* timers every run loop iteration checking if they've gone off, their code also starts NSLogging warnings if you have more than 1000 timers. I have no idea if apple's solution is better than GNUstep's, but if it isn't, the single timer approach would be vastly beneficial.
Tom Davie_______________________________________________
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