-----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 (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
