Consoles/Threads/Timers

Hi - bit of a theoretical question here

In a console app I’ve got a timer firing every 30 seconds that in turn fires a thread. This is my normal approach.

Just struck me “Do I need the timer?” At the end of the thread process could I sleep that thread and then run the process again?

So my App.Run event would have
If Thread.State = Thread.NotRunning Then Thread.Run
Rather than
app.DoEvents

My Thread run event would call a method which controls the process and this gets called again once the thread.sleep wakes.

Not sure whether this is a good thing or not. I’m wondering whether I’d be leaving my app open to problems(?)

Just wanted to get some other thoughts…

I don’t know but I immediately thought StackOverflow exception … isn’t there a circular reference in there, the method calls the thread which calls the method which calls the thread …

Well, if the thread ever ended then maybe - but the thread never ends.

The App.Run event fires the thead.run event which in turn fires a controlling method which is within the thread itself. Once the process has finished the thread.sleep event pauses for 30 seconds or so then when it wakes it starts the controlling method again.

So the thread doesn’t end and the App.run thread.state command (in my first post) means there can only ever be one thread.

It’s an interesting one…

Another question might be, If this is a console app, do you really need a thread?

This particular app I’m experimenting with has more than one thread running as it performs multiple processes. I could easily split the app processes into it’s own apps - no problem.

Just trying to work out if it’s a “worse” approach compared to timers really. Is there a reason not to sleep the thread? My playing today has not really shown to me a reason.

[Edit] - I suppose the fact it’s a console app is neither here or there. Question applies to desktop/web apps as well.

[quote=18014:@Patrick Delaney]Hi - bit of a theoretical question here

In a console app I’ve got a timer firing every 30 seconds that in turn fires a thread. This is my normal approach.

Just struck me “Do I need the timer?” At the end of the thread process could I sleep that thread and then run the process again?

So my App.Run event would have
If Thread.State = Thread.NotRunning Then Thread.Run
Rather than
app.DoEvents

My Thread run event would call a method which controls the process and this gets called again once the thread.sleep wakes.

Not sure whether this is a good thing or not. I’m wondering whether I’d be leaving my app open to problems(?)

Just wanted to get some other thoughts…[/quote]

For threaded tasks that we want to process periodically, we use the Thread.Sleep method in all of our Desktop, Web and Console apps. I’m not sure if one approach is necessarily better than the other but this approach does appear to be simpler because it eliminates the Timer class altogether.

Exactly - I’m so used to using the timer in these instances I do it without thinking.

I suddenly thought - “Why do I need the timer at all !?!” - one less thing to worry about.

[quote=18100:@Patrick Delaney]Exactly - I’m so used to using the timer in these instances I do it without thinking.

I suddenly thought - “Why do I need the timer at all !?!” - one less thing to worry about.[/quote]

Less is more. :wink: