Re: System.Threading.Timers
Chris Anderson <[email protected]>
| Newsgroups | gmane.comp.windows.devel.dotnet.cx |
|---|---|
| Message-ID | <[email protected]> |
FWIW you could have a single timer that ticks away every second [1], and have all the objects subscribe to it's fire event. They can then just check the time to see if they should do anything or simply return. Then, instead of passing in the argument that says whether an internal timer should be used, you can simply pass in a reference to an existing timer. Just a thought Chris [1] or more or less, depending on how often your timers fire > -----Original Message----- > From: Discussion relating to the specifics of the C# and > Managed C++ languages [mailto:[email protected]] > On Behalf Of Peter Osucha > Sent: 05 June 2006 15:01 > To: [email protected] > Subject: [DOTNET-CX] System.Threading.Timers > > I have collection of objects (MyObj) - maybe up to 32 of them > - that all need to independently 'wait' for an elapsed time > before doing something once a method is called on them. So I > have been reviewing what looks like the best option - Timer > objects from the System.Threading.Timers namespace. > What I am wondering is - what kind of impact having so many > active timers might have on my machine, application? > > When the MyObj objects are created, one argument passed to > the constructor tells the object whether it will be using an > internal timer so I do have the capability to not > automatically create a timer with each MyObj - still, I > wonder about having so many timers objects around... > > Peter > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > > =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com