Re: creating multiple NSTimers
Re: creating multiple NSTimers
- Subject: Re: creating multiple NSTimers
- From: Conrad Shultz <email@hidden>
- Date: Fri, 30 Sep 2011 01:37:00 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/30/11 12:29 AM, Thomas Davie wrote:
>> 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.
OK, I'll grant you it's a fast re-sort, but you still have to find the
new insertion point and move the index (if needed).
>> 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.
Of course, though my gut feeling (admittedly happening at a time of
day where I'm fast fading and likely to put my foot in my mouth...) is
that the locking would be simpler if one had discrete timers that can
be scattered across threads (or run their invocations on separate
threads - though that might be unsuitable for the task at hand). I
haven't sat down and implemented this (as you evidently have), so I
must confess I don't have much to stand on here.
>> 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.
OK, my apologies, I got turned around and had the earlier suggestion
about a high-resolution poll still stuck in my head. You're
absolutely right - no one is suggesting polling in the above.
>> 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.
Wow, I have to imagine there are a fair number of timers getting fired
off throughout the system all the time for various tasks and that
Apple would have optimized it more thoroughly.
But a cursory inspection of the most recent open source CFRunLoop.c
suggests that indeed is what is happening inside __CFRunLoopDoTimers.
It's possible that I'm missing something in my tired state, but it
sure does look like a simple loop. (There's a lot of magic happening
in __CFRunLoopDoTimer, but it still gets called during each loop
iteration.)
Huh... color me surprised.
Thanks for the response (and putting up with me).
- --
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6Ff6wACgkQaOlrz5+0JdXnYwCeL8dCMMzWdLxigqgak56ADr9U
jQUAnjltbDhavl2/PiwUiD7O+HofAU/Q
=Yo8x
-----END PGP SIGNATURE-----
_______________________________________________
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