Re: creating multiple NSTimers
Thanks for the discussion. What I implemented last night was what Graham had suggested. I simply bind my table column values to an NSArrayController controller and observed by KVO in my set box object. It works great. I think this is also what Conrad had meant as well. Simply changing the time updates or invalidates the timer for each box. It is far more elegant that what I was originally doing. Not to carry this discussion too long, I created this confusion in my head by looking at a project I did 4 years ago while developing a sprinkler controller. In that project I ended up creating a schedule object which was a property for each relay on a controller board which was as an object as well. Each relay (sprinkler zone) had an address, on and off commands and an indeterminate number of schedule objects as properties. If you think about this it is quite challenging as you can very easily end up with 100's of timers on the run loop at any one time. Many of these timers (on a 7 day schedule) would be sitting around for days waiting to fire. For just one relay you would have at a minimum 2 timers (on and off timers) a day. Each relay was on a relay board with 12 relays. Complicating matters was the fact that here (drought stricken Texas) many areas are running a sprinkler zone at multiple short interval times per day (mainly at night). To avoid having all of these timers on the run loop I ended up using the one initial timer that when fired started a loop through the array of timers. But keep in mind that each "on" command timer also had an "off" command timer as well as setting up the next on timer. Also keep in mind that only one zone can be on at a time due to water pressure (this being the difference between this set top box project and the sprinkler project). etc. Anyway food for thought. Tom On Sep 30, 2011, at 3:37 AM, Conrad Shultz wrote: > -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... c
Re: creating multiple NSTimers
-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
Re: creating multiple NSTimers
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 (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
Re: creating multiple NSTimers
-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). 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. And as Graham mentioned, polling is probably less CPU and power efficient than using timers anyway. 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? - -- 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/ iEYEARECAAYFAk6FbZoACgkQaOlrz5+0JdUAuQCcC3cpCXFJSa7/AMJcrca7l749 1zcAn1tM1yHYuZkoZhvCMPVdAA1UBX4u =tv8r -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
Re: creating multiple NSTimers
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. -- GG ___ 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
Re: creating multiple NSTimers
Whoops, didn¹t reset the title. Sorry. On 9/29/11 8:25 PM, "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. > > > On 9/29/11 8:06 PM, "cocoa-dev-requ...@lists.apple.com" > wrote: > >>> > Perhaps, instead of timers, you use objects that represent one of these >>> set-top boxes and the time at which they should be shutdown. And instead of >>> scheduling and managing timer, you manage the domain objects instead. Then, >>> you have one timer, that checks all of your objects and sees if they should >>> be shut down. >> >> >> But when re-reading the thread I see this is exactly what John suggested: >> >>> > Could you use a single, repeating timer with sufficient resolution for >>> your purposes and an array or dictionary storing the needed timing state? >>> Then update state appropriately at each fire of the single timer?" > ___ 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
Re: creating multiple NSTimers
Bingo! Thanks. This is where I was going wrong. I saw John and Jamie's responses earlier and got me thinking in objects again. But still wasn't putting it together. I had a mental block and was not thinking of the timers as properties of the boxes. Just kept getting stuck on the NSTimer object being the object. Man it is hard to get off of a train of though sometimes. Ultimately each facility has between 20 and 30 boxes. I really did not want to poll. Thanks again Tom On Sep 29, 2011, at 7:27 PM, Graham Cox wrote: > Timers are objects, and can be retained like any other independently of > whether they are scheduled on a run loop or not. The run loop will > additionally retain the timer, but that's its business. > > In the object that represents the set-top box, just add a 'timer' property > (retained), so that you can get the timer associated with the box. Then you > are free to invalidate it, reschedule it, add it or remove it from the run > loop at will. While leaving the run loop to manage its timers is the usual > M.O., if you need more control, then all you need to do is take it. > > Depending on how many set-top boxes there are likely to be (I'm guessing tens > rather than thousands), then a separate timer per box is probably a good idea > rather than have one timer which is repeatedly compared against a list of > schedule times, which amounts to polling and hence will mean waking up the > thread more often than necessary. > > --Graham > > > On 30/09/2011, at 9:48 AM, Tom Hohensee wrote: > >> Sorry, I started this out wrong. I am probably over thinking this to the >> point of confusion. Here is where I am. >> I have an application for a facility that uses a number of ip enabled set >> top boxes to drive TV's throughout the place. Each box is to be shutdown >> at certain times of the day depending on what part of the facility is closed >> for the day. In my app the user sets up a configuration in an NSTable >> whereby each device is set to shut down at a certain time each day. From >> this configuration, I setup timers to correspond to the shutdown time and >> have them repeat each 24 hours. I originally thought I would simply load >> each into the runloop using NSTimers class method >> +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without >> retaining a reference to it. But I ran into the problem of the user >> changing a device's shutdown time while the app is running. I needed to >> retain a reference to the timer to invalidate it . In other words, if the >> user comes along and wants to change the configuration (a shut down time) of >> one device while the app is running I need to be able to stop the timer that >> is currently in the run loop and use the new configuration. Without >> invalidating that timer would I not have an active timer in the run loop on >> top of what is created by new configuration? I then moved on the creating >> timers and instead of loading them into the run loop I would load them into >> an array and and sort them according to time. I then loop through the array >> loading only the first timer of the array into the run loop and retain a >> reference to it. Each firing of the timer loads the next timer into the run >> loop and retains a reference to it. But this has other issues particularly >> when firing times are real close together. >> >> At this point I need a fresh prospective on this. Any thoughts would be >> greatly appreciated. > > ___ > > 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/tomhoh%40mac.com > > This email sent to tom...@mac.com ___ 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
Re: creating multiple NSTimers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/11 4:48 PM, Tom Hohensee wrote: > Sorry, I started this out wrong. I am probably over thinking > this to the point of confusion. Here is where I am. I have an > application for a facility that uses a number of ip enabled set top > boxes to drive TV's throughout the place. Each box is to be > shutdown at certain times of the day depending on what part of the > facility is closed for the day. In my app the user sets up a > configuration in an NSTable whereby each device is set to shut down > at a certain time each day. From this configuration, I setup > timers to correspond to the shutdown time and have them repeat each > 24 hours. I originally thought I would simply load each into the > runloop using NSTimers class method > +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. > without retaining a reference to it. But I ran into the problem > of the user changing a device's shutdown time while the app is > running. I needed to retain a reference to the timer to invalidate > it . In other words, if the user comes along and wants to change > the configuration (a shut down time) of one device while the app > is running I need to be able to stop the timer that is currently in > the run loop and use the new configuration. Without invalidating > that timer would I not have an active timer in the run loop on top > of what is created by new configuration? I then moved on the > creating timers and instead of loading them into the run loop I > would load them into an array and and sort them according to time. > I then loop through the array loading only the first timer of the > array into the run loop and retain a reference to it. Each firing > of the timer loads the next timer into the run loop and retains a > reference to it. But this has other issues particularly when firing > times are real close together. > > At this point I need a fresh prospective on this. Any thoughts > would be greatly appreciated. OK, from the description I still don't see why you couldn't schedule the timers on the run loop and keep references to them in an appropriately keyed dictionary. When someone needs to edit the shutdown time you simply fetch the timer from the dictionary and - -setFireDate:. You would also have the ability to invalidate timers and remove them from the dictionary. Just make sure you remove the timers from the dictionary once fired/invalidated. (You could probably avoid this step by using zeroing weak references if you really wanted.) The polling approach described by John and Jamie would presumably also work, but I would consider the dictionary approach more straightforward. - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOhQ1saOlrz5+0JdURAvEhAKCK7mCy5d/Y2Byx3CrKGPtyJ2PgowCffXNt oCPRXWNVcHVyCLeRIuGQSyI= =dH8W -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
Re: creating multiple NSTimers
Timers are objects, and can be retained like any other independently of whether they are scheduled on a run loop or not. The run loop will additionally retain the timer, but that's its business. In the object that represents the set-top box, just add a 'timer' property (retained), so that you can get the timer associated with the box. Then you are free to invalidate it, reschedule it, add it or remove it from the run loop at will. While leaving the run loop to manage its timers is the usual M.O., if you need more control, then all you need to do is take it. Depending on how many set-top boxes there are likely to be (I'm guessing tens rather than thousands), then a separate timer per box is probably a good idea rather than have one timer which is repeatedly compared against a list of schedule times, which amounts to polling and hence will mean waking up the thread more often than necessary. --Graham On 30/09/2011, at 9:48 AM, Tom Hohensee wrote: > Sorry, I started this out wrong. I am probably over thinking this to the > point of confusion. Here is where I am. > I have an application for a facility that uses a number of ip enabled set top > boxes to drive TV's throughout the place. Each box is to be shutdown at > certain times of the day depending on what part of the facility is closed for > the day. In my app the user sets up a configuration in an NSTable whereby > each device is set to shut down at a certain time each day. From this > configuration, I setup timers to correspond to the shutdown time and have > them repeat each 24 hours. I originally thought I would simply load each into > the runloop using NSTimers class method > +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without > retaining a reference to it. But I ran into the problem of the user changing > a device's shutdown time while the app is running. I needed to retain a > reference to the timer to invalidate it . In other words, if the user comes > along and wants to change the configuration (a shut down time) of one device > while the app is running I need to be able to stop the timer that is > currently in the run loop and use the new configuration. Without > invalidating that timer would I not have an active timer in the run loop on > top of what is created by new configuration? I then moved on the creating > timers and instead of loading them into the run loop I would load them into > an array and and sort them according to time. I then loop through the array > loading only the first timer of the array into the run loop and retain a > reference to it. Each firing of the timer loads the next timer into the run > loop and retains a reference to it. But this has other issues particularly > when firing times are real close together. > > At this point I need a fresh prospective on this. Any thoughts would be > greatly appreciated. ___ 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
Re: creating multiple NSTimers
Forgot to send to list: > Perhaps, instead of timers, you use objects that represent one of these > set-top boxes and the time at which they should be shutdown. And instead of > scheduling and managing timer, you manage the domain objects instead. Then, > you have one timer, that checks all of your objects and sees if they should > be shut down. But when re-reading the thread I see this is exactly what John suggested: > Could you use a single, repeating timer with sufficient resolution for your > purposes and an array or dictionary storing the needed timing state? Then > update state appropriately at each fire of the single timer?" On Sep 29, 2011, at 7:48 PM, Tom Hohensee wrote: > Sorry, I started this out wrong. I am probably over thinking this to the > point of confusion. Here is where I am. > I have an application for a facility that uses a number of ip enabled set top > boxes to drive TV's throughout the place. Each box is to be shutdown at > certain times of the day depending on what part of the facility is closed for > the day. In my app the user sets up a configuration in an NSTable whereby > each device is set to shut down at a certain time each day. From this > configuration, I setup timers to correspond to the shutdown time and have > them repeat each 24 hours. I originally thought I would simply load each > into the runloop using NSTimers class method > +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without > retaining a reference to it. But I ran into the problem of the user changing > a device's shutdown time while the app is running. I needed to retain a > reference to the timer to invalidate it . In other words, if the user comes > along and wants to change the configuration (a shut down time) of one device > while the app is running I need to be able to stop the timer that is > currently in the run loop and use the new configuration. Without > invalidating that timer would I not have an active timer in the run loop on > top of what is created by new configuration? I then moved on the creating > timers and instead of loading them into the run loop I would load them into > an array and and sort them according to time. I then loop through the array > loading only the first timer of the array into the run loop and retain a > reference to it. Each firing of the timer loads the next timer into the run > loop and retains a reference to it. But this has other issues particularly > when firing times are real close together. > > At this point I need a fresh prospective on this. Any thoughts would be > greatly appreciated. > > Tom > > > On Sep 29, 2011, at 5:15 PM, David Duncan wrote: > >> I think you need to backup and explain exactly what your requirements are. >> If you really do need to track these timers, you will probably need an array >> or dictionary, but if these timers are all one-shot and they configure the >> next timer to execute, there seems little reason to maintain your own owning >> reference to them... >> >> On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: >> >>> Yes. What I have worked on is using an array of timers fired sequentially. >>> Each firing of the timer sets up the next one in the array. Each new >>> addition to the array requires invalidating of the active timer and >>> reordering of the array according to times. But i have run into problems >>> when two or more timers are set to fire at the same time. >>> >>> Tom >>> >>> On Sep 29, 2011, at 4:51 PM, David Duncan wrote: >>> On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: > However, I do not know wether the user will have 1 device or 100 devices. > Do I have to setup a finite amount of timers (ultimately having a limit > on the number of devices that can be added) or is there a better way? I > have googled for a while now trying to find example code but have come up > empty (plenty of finite examples). I see there are timer applications > out there that seem to handle an infinite number of timers. Have you looked into NSMutableArray? -- David Duncan ___ 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/tomhoh%40mac.com This email sent to tom...@mac.com >>> >> >> -- >> David Duncan >> > > ___ > > 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-
Re: creating multiple NSTimers
Sorry, I started this out wrong. I am probably over thinking this to the point of confusion. Here is where I am. I have an application for a facility that uses a number of ip enabled set top boxes to drive TV's throughout the place. Each box is to be shutdown at certain times of the day depending on what part of the facility is closed for the day. In my app the user sets up a configuration in an NSTable whereby each device is set to shut down at a certain time each day. From this configuration, I setup timers to correspond to the shutdown time and have them repeat each 24 hours. I originally thought I would simply load each into the runloop using NSTimers class method +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without retaining a reference to it. But I ran into the problem of the user changing a device's shutdown time while the app is running. I needed to retain a reference to the timer to invalidate it . In other words, if the user comes along and wants to change the configuration (a shut down time) of one device while the app is running I need to be able to stop the timer that is currently in the run loop and use the new configuration. Without invalidating that timer would I not have an active timer in the run loop on top of what is created by new configuration? I then moved on the creating timers and instead of loading them into the run loop I would load them into an array and and sort them according to time. I then loop through the array loading only the first timer of the array into the run loop and retain a reference to it. Each firing of the timer loads the next timer into the run loop and retains a reference to it. But this has other issues particularly when firing times are real close together. At this point I need a fresh prospective on this. Any thoughts would be greatly appreciated. Tom On Sep 29, 2011, at 5:15 PM, David Duncan wrote: > I think you need to backup and explain exactly what your requirements are. If > you really do need to track these timers, you will probably need an array or > dictionary, but if these timers are all one-shot and they configure the next > timer to execute, there seems little reason to maintain your own owning > reference to them... > > On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: > >> Yes. What I have worked on is using an array of timers fired sequentially. >> Each firing of the timer sets up the next one in the array. Each new >> addition to the array requires invalidating of the active timer and >> reordering of the array according to times. But i have run into problems >> when two or more timers are set to fire at the same time. >> >> Tom >> >> On Sep 29, 2011, at 4:51 PM, David Duncan wrote: >> >>> On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: >>> However, I do not know wether the user will have 1 device or 100 devices. Do I have to setup a finite amount of timers (ultimately having a limit on the number of devices that can be added) or is there a better way? I have googled for a while now trying to find example code but have come up empty (plenty of finite examples). I see there are timer applications out there that seem to handle an infinite number of timers. >>> >>> >>> Have you looked into NSMutableArray? >>> -- >>> David Duncan >>> >>> ___ >>> >>> 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/tomhoh%40mac.com >>> >>> This email sent to tom...@mac.com >> > > -- > David Duncan > ___ 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
Re: creating multiple NSTimers
Hi Tom-
Could you use a single, repeating timer with sufficient resolution for your
purposes and an array or dictionary storing the needed timing state? Then
update state appropriately at each fire of the single timer?
Array {
Timing Item 1 {
currentTime: 24.2
running: YES
expires: 60.0
}
Timing Item 2 {
… etc.
}
}
- (void)doSomething:(NSTimer *)timer
{
// increment timing state
// expire overdue items
// etc.
}
Not sure of what you're trying to accomplish; perhaps this a different way to
consider the issue. HTH!
John
John Pannell
http://www.positivespinmedia.com
On Sep 29, 2011, at 4:06 PM, Tom Hohensee wrote:
> Yes. What I have worked on is using an array of timers fired sequentially.
> Each firing of the timer sets up the next one in the array. Each new
> addition to the array requires invalidating of the active timer and
> reordering of the array according to times. But i have run into problems
> when two or more timers are set to fire at the same time.
>
> Tom
___
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
Re: creating multiple NSTimers
On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: > Yes. What I have worked on is using an array of timers fired sequentially. > Each firing of the timer sets up the next one in the array. Each new > addition to the array requires invalidating of the active timer and > reordering of the array according to times. But i have run into problems > when two or more timers are set to fire at the same time. What you’re describing sounds like the work that the runloop performs internally to manage multiple active timers. Why not let the runloop do the work for you? Just start up all the timers in parallel and wait for them to fire. —Jens___ 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
Re: creating multiple NSTimers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/11 3:06 PM, Tom Hohensee wrote: > Yes. What I have worked on is using an array of timers fired > sequentially. Each firing of the timer sets up the next one in the > array. Each new addition to the array requires invalidating of the > active timer and reordering of the array according to times. But i > have run into problems when two or more timers are set to fire at > the same time. I don't really follow what you are doing here, but given the original description of your problem, wouldn't an NSMutableDictionary keyed by IP be a good choice? Then you can just add/remove timers as needed and not have to worry about shifting an array. If you are trying to get the timers ordered by when they will fire, do not overlook, e.g., NSDictionary's –keysSortedByValueUsingComparator:. - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOhO6raOlrz5+0JdURAoLMAJ4qJwuj5/6riE4jhtc3n6mafOYxdACbBOJP yUKa53Va5NYPgITcnpJJyPU= =xa6z -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
Re: creating multiple NSTimers
I think you need to backup and explain exactly what your requirements are. If you really do need to track these timers, you will probably need an array or dictionary, but if these timers are all one-shot and they configure the next timer to execute, there seems little reason to maintain your own owning reference to them... On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: > Yes. What I have worked on is using an array of timers fired sequentially. > Each firing of the timer sets up the next one in the array. Each new > addition to the array requires invalidating of the active timer and > reordering of the array according to times. But i have run into problems > when two or more timers are set to fire at the same time. > > Tom > > On Sep 29, 2011, at 4:51 PM, David Duncan wrote: > >> On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: >> >>> However, I do not know wether the user will have 1 device or 100 devices. >>> Do I have to setup a finite amount of timers (ultimately having a limit on >>> the number of devices that can be added) or is there a better way? I have >>> googled for a while now trying to find example code but have come up empty >>> (plenty of finite examples). I see there are timer applications out there >>> that seem to handle an infinite number of timers. >> >> >> Have you looked into NSMutableArray? >> -- >> David Duncan >> >> ___ >> >> 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/tomhoh%40mac.com >> >> This email sent to tom...@mac.com > -- David Duncan ___ 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
Re: creating multiple NSTimers
Yes. What I have worked on is using an array of timers fired sequentially. Each firing of the timer sets up the next one in the array. Each new addition to the array requires invalidating of the active timer and reordering of the array according to times. But i have run into problems when two or more timers are set to fire at the same time. Tom On Sep 29, 2011, at 4:51 PM, David Duncan wrote: > On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: > >> However, I do not know wether the user will have 1 device or 100 devices. >> Do I have to setup a finite amount of timers (ultimately having a limit on >> the number of devices that can be added) or is there a better way? I have >> googled for a while now trying to find example code but have come up empty >> (plenty of finite examples). I see there are timer applications out there >> that seem to handle an infinite number of timers. > > > Have you looked into NSMutableArray? > -- > David Duncan > > ___ > > 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/tomhoh%40mac.com > > This email sent to tom...@mac.com ___ 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
Re: creating multiple NSTimers
On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: > However, I do not know wether the user will have 1 device or 100 devices. Do > I have to setup a finite amount of timers (ultimately having a limit on the > number of devices that can be added) or is there a better way? I have > googled for a while now trying to find example code but have come up empty > (plenty of finite examples). I see there are timer applications out there > that seem to handle an infinite number of timers. Have you looked into NSMutableArray? -- David Duncan ___ 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
Re: creating multiple NSTimers
Can't you use a loop and then stuff the timers into an NSMutableArray or NSMutableDictionary to access? On Thu, Sep 29, 2011 at 5:47 PM, Tom Hohensee wrote: > For the life of me I cannot figure this one out. I need to create an > indeterminate amount of timers for an app I am working on. The app is petty > simple. For example, provide a list of ip enabled devices with times to > shut off and the app executes the device's shutdown at the specified time. > I need to retain a reference to each timer so that I can invalidate the > timer if necessary. Obviously setting up one timer or two timers is not a > problem. > > NSTimer *myTimer1; > NSTimer *myTimer2; > etc. > > However, I do not know wether the user will have 1 device or 100 devices. > Do I have to setup a finite amount of timers (ultimately having a limit on > the number of devices that can be added) or is there a better way? I have > googled for a while now trying to find example code but have come up empty > (plenty of finite examples). I see there are timer applications out there > that seem to handle an infinite number of timers. > > Thanks > Tom___ > > 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/edolecki%40gmail.com > > This email sent to edole...@gmail.com > ___ 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
creating multiple NSTimers
For the life of me I cannot figure this one out. I need to create an indeterminate amount of timers for an app I am working on. The app is petty simple. For example, provide a list of ip enabled devices with times to shut off and the app executes the device's shutdown at the specified time. I need to retain a reference to each timer so that I can invalidate the timer if necessary. Obviously setting up one timer or two timers is not a problem. NSTimer *myTimer1; NSTimer *myTimer2; etc. However, I do not know wether the user will have 1 device or 100 devices. Do I have to setup a finite amount of timers (ultimately having a limit on the number of devices that can be added) or is there a better way? I have googled for a while now trying to find example code but have come up empty (plenty of finite examples). I see there are timer applications out there that seem to handle an infinite number of timers. Thanks Tom___ 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
