How to Generate an Accurate Timer Tick
in [Dot Net]
|
Prev: problem sending email from non-administrator account
Next: BUY SPANISH FAKE PASSPORT/FAKE SPANISH ID CARD SALE ONLINE/SWISS FALSE PASSPORT BUY/UK FAKE ID CARD
From: DickGrier on 22 May 2010 13:00 It is hard for me to imagine a scenario where conventional timer messages will be delayed sufficiently long enough to cause trouble with your application. 5-10 seconds is a huge window. If you really are seeing such a problem, the only thing that I can imagine is something that is seriously wrong. This certainly isn't something that I've seen. Have you tried System.Threading.Timer instead -- this create a threaded timer? If this doesn't work, I think you need to look more closely at your system to see where the hog resides. -- Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net Author of Visual Basic Programmer's Guide to Serial Communications, 4th Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July 2006.
From: Tom Shelton on 22 May 2010 14:13 Charles explained on 5/22/2010 : > Thinking about it further, the downside of this approach is that the interval > between 'ticks' is not 10 seconds anymore. It is 10 seconds + length of time > task takes. Perhaps that's not the end of the world, but I might have to > factor that in somehow. > > Charles > > ThreadPool.QueueUserWorkItem :) -- Tom Shelton
From: Willem van Rumpt on 22 May 2010 17:16 On 22-5-2010 9:51, Charles wrote: > Thinking about it further, the downside of this approach is that the > interval between 'ticks' is not 10 seconds anymore. It is 10 seconds + > length of time task takes. Perhaps that's not the end of the world, but > I might have to factor that in somehow. > > Charles > But this will always be a factor to consider, whatever scenario you choose. You should ask yourself whether you want the signalling system to have some form of reentrancy. In other words: Is it allowed to be signalled while a previous signal is still being processed? If yes, then the question should be: Is the order of processing the signals relevant or not? If it's not, you can just start the task on a separate thread, or queue it on the threadpool. If it is, you'll have to setup some sort of queue, that processes the signals asynchroniously, but in queued order. If no, then there's little you can do about it. Either you make sure the tasks finishes within the signalling time window (which may or may not be possible, but will always be very tough to guarantee), or you give up on reentrancy of the signal. -- Willem van Rumpt
From: Charles on 23 May 2010 07:51 Hi Tom > ThreadPool.QueueUserWorkItem I'm not sure I follow. Charles "Tom Shelton" <tom_shelton(a)comcast.invalid> wrote in message news:ht96sg$gu3$1(a)news.eternal-september.org... > Charles explained on 5/22/2010 : >> Thinking about it further, the downside of this approach is that the >> interval between 'ticks' is not 10 seconds anymore. It is 10 seconds + >> length of time task takes. Perhaps that's not the end of the world, but I >> might have to factor that in somehow. >> >> Charles >> >> > ThreadPool.QueueUserWorkItem :) > > -- > Tom Shelton > >
From: Charles on 23 May 2010 07:53
I've just read Willem's reply and I get it now :-) Charles "Tom Shelton" <tom_shelton(a)comcast.invalid> wrote in message news:ht96sg$gu3$1(a)news.eternal-september.org... > Charles explained on 5/22/2010 : >> Thinking about it further, the downside of this approach is that the >> interval between 'ticks' is not 10 seconds anymore. It is 10 seconds + >> length of time task takes. Perhaps that's not the end of the world, but I >> might have to factor that in somehow. >> >> Charles >> >> > ThreadPool.QueueUserWorkItem :) > > -- > Tom Shelton > > |