Multiple Threads Within the IDE

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

I was noticing that when I run a multi-threaded app from within the IDE and
then I close the main form (which spun off all of the threads), that the
Stop/Pause VCR buttons in the debugger are still available & working. It's
like closing the form did not actually cancel the threads.
Indeed.
From my earlier discussions on the newsgroup, I know how people already feel
about Thread.Abort(), so I was wondering what I need to do to "clean up"
when closing a main form that has spun off worker threads (I was under the
impression that this cleanup would automatically happen, but seeing the
Stop/Pause VCR buttons on the debugger being active & working tell me
otherwise).

When you spin off the worker threads, make them background instead of
foreground threads. The CLR will shut down when all foreground threads
(eg your UI thread) have finished.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

well if you just want the trheads to terminate when teh main thread does set their IsBackground property to true. If you want the threads to come down in a controlled fashion, signal them (by an event, flag or Interrupt) and issue a Join on them before the form closes.

The main issue is that threads created uwing the Thread class will, by default, keep your process running.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<Og************ **@TK2MSFTNGP09 .phx.gbl>

I was noticing that when I run a multi-threaded app from within the IDE and
then I close the main form (which spun off all of the threads), that the
Stop/Pause VCR buttons in the debugger are still available & working. It's
like closing the form did not actually cancel the threads.

From my earlier discussions on the newsgroup, I know how people already feel
about Thread.Abort(), so I was wondering what I need to do to "clean up"
when closing a main form that has spun off worker threads (I was under the
impression that this cleanup would automatically happen, but seeing the
Stop/Pause VCR buttons on the debugger being active & working tell me
otherwise).

Any thoughts would be appreciated.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004

[microsoft.publi c.dotnet.langua ges.csharp]

So, what is the recommended method for shutting down threads spun off my a
main form in a WinFOrms app?

1. Create all worker threads by setting the IsBackground property to true?
2. Call Thread.Interrup t() followed by Thread.Join() within the Form's
Close event for all worker threads?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Richard Blewett [DevelopMentor]" <ri******@devel op.com> wrote in message
news:es******** ******@TK2MSFTN GP12.phx.gbl...

well if you just want the trheads to terminate when teh main thread does
set their IsBackground property to true. If you want the threads to come
down in a controlled fashion, signal them (by an event, flag or Interrupt)
and issue a Join on them before the form closes.

The main issue is that threads created uwing the Thread class will, by
default, keep your process running.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<Og************ **@TK2MSFTNGP09 .phx.gbl>

I was noticing that when I run a multi-threaded app from within the IDE
and
then I close the main form (which spun off all of the threads), that the
Stop/Pause VCR buttons in the debugger are still available & working. It's
like closing the form did not actually cancel the threads.

From my earlier discussions on the newsgroup, I know how people already
feel
about Thread.Abort(), so I was wondering what I need to do to "clean up"
when closing a main form that has spun off worker threads (I was under the
impression that this cleanup would automatically happen, but seeing the
Stop/Pause VCR buttons on the debugger being active & working tell me
otherwise).

Any thoughts would be appreciated.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004

[microsoft.publi c.dotnet.langua ges.csharp]

As with all important questions ... it depends. If the threads need to come down in a controlled fashion then the UI thread, once it exits from Application.Run can Join on the threads. If they don't need to come down in a controlled fashion but just need to terminate, make them background.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<uX************ *@TK2MSFTNGP11. phx.gbl>

So, what is the recommended method for shutting down threads spun off my a
main form in a WinFOrms app?

1. Create all worker threads by setting the IsBackground property to true?
2. Call Thread.Interrup t() followed by Thread.Join() within the Form's
Close event for all worker threads?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

Any reason not to put the Interrupt() and Join() calls in the Form's Close
event handler?

BTW ... You guys have provided a lot of good information here - a lot more
than is show in the various threading articles and books (a lot of this IS
NEVER MENTIONED). Makes me think that an article written from the
beginner's perspective, but with THIS information, would be quite helpful.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Richard Blewett [DevelopMentor]" <ri******@devel op.com> wrote in message
news:uB******** *******@TK2MSFT NGP12.phx.gbl.. .

As with all important questions ... it depends. If the threads need to
come down in a controlled fashion then the UI thread, once it exits from
Application.Run can Join on the threads. If they don't need to come down
in a controlled fashion but just need to terminate, make them background.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<uX************ *@TK2MSFTNGP11. phx.gbl>

So, what is the recommended method for shutting down threads spun off my a
main form in a WinFOrms app?

1. Create all worker threads by setting the IsBackground property to true?
2. Call Thread.Interrup t() followed by Thread.Join() within the Form's
Close event for all worker threads?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

Any reason not to put the Interrupt() and Join() calls in the Form's Close
event handler?
I would suggest not using Interrupt, myself - it's not a terribly
nicely controlled way of doing things. I would have a property which is
polled regularly by each worker thread. The only downside of that is
that if a thread gets "stuck" it could hold the app up. To stop that
from being a problem, you could have an extra background thread which
*does* call Thread.Interrup t, or Thread.Abort, or even Environment.Exi t
if it's still running say 5 seconds after the UI has shut down.

For code demonstrating what I mean about the polling, see
http://www.yoda.arachsys.com/csharp/...shutdown.shtml

As for calling Join() - why bother? What would you want to do after
you'd waited for them? If you're just going to return, then let the
main thread just die and the other threads can die in their own time.
BTW ... You guys have provided a lot of good information here - a lot more
than is show in the various threading articles and books (a lot of this IS
NEVER MENTIONED). Makes me think that an article written from the
beginner's perspective, but with THIS information, would be quite helpful.

If you have any suggestions for how I can improve my article at
http://www.pobox.com/~skeet/csharp/threads I'd be keen to improve it.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

My only tips would be to not rely on console apps (not much of a real-world
scenario) and move your thread code out from within the Form's class code
and into its own class (as you'd probably see in the real world). I found
out a bunch of scope stuff that changes once you try and do delegates off of
methods within classes, rather than just a method within the Form class.

I'd also recommend somehow that you get the word out about your article. It
doesn't hit very high in Google, and the one's that do are the articles I'm
complaining about right now - the ones that just show console apps with no
meat, no talk about how to safely update the UI from a worker thread, and
how to safely bring down worker threads.

Thanks for asking my opinion.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** @msnews.microso ft.com...

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

Any reason not to put the Interrupt() and Join() calls in the Form's
Close
event handler?

I would suggest not using Interrupt, myself - it's not a terribly
nicely controlled way of doing things. I would have a property which is
polled regularly by each worker thread. The only downside of that is
that if a thread gets "stuck" it could hold the app up. To stop that
from being a problem, you could have an extra background thread which
*does* call Thread.Interrup t, or Thread.Abort, or even Environment.Exi t
if it's still running say 5 seconds after the UI has shut down.

For code demonstrating what I mean about the polling, see
http://www.yoda.arachsys.com/csharp/...shutdown.shtml

As for calling Join() - why bother? What would you want to do after
you'd waited for them? If you're just going to return, then let the
main thread just die and the other threads can die in their own time.

BTW ... You guys have provided a lot of good information here - a lot
more
than is show in the various threading articles and books (a lot of this
IS
NEVER MENTIONED). Makes me think that an article written from the
beginner's perspective, but with THIS information, would be quite
helpful.

If you have any suggestions for how I can improve my article at
http://www.pobox.com/~skeet/csharp/threads I'd be keen to improve it.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Maybe I missed this in your article (but I don't think so), but ... Is there
a reason that a ThreadInterrupt edException does not get raised in a worker
thread if that worker thread just loops without having a Thread.Sleep
command somewhere in the worker thread's loop (even if the Thread is marked
for background before it's started)?

I would've thought that a Sleep wasn't necessary when marking it as
IsBackground before starting it, but until I put at least a Thread.Sleep(0)
(thus giving up at least that timeslice within the loop), my
Thread.Interrup t() from the main thread never generates an exception within
the try...catch clause of my worker thread that surrounds the loop.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** @msnews.microso ft.com...

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

Any reason not to put the Interrupt() and Join() calls in the Form's
Close
event handler?

I would suggest not using Interrupt, myself - it's not a terribly
nicely controlled way of doing things. I would have a property which is
polled regularly by each worker thread. The only downside of that is
that if a thread gets "stuck" it could hold the app up. To stop that
from being a problem, you could have an extra background thread which
*does* call Thread.Interrup t, or Thread.Abort, or even Environment.Exi t
if it's still running say 5 seconds after the UI has shut down.

For code demonstrating what I mean about the polling, see
http://www.yoda.arachsys.com/csharp/...shutdown.shtml

As for calling Join() - why bother? What would you want to do after
you'd waited for them? If you're just going to return, then let the
main thread just die and the other threads can die in their own time.

BTW ... You guys have provided a lot of good information here - a lot
more
than is show in the various threading articles and books (a lot of this
IS
NEVER MENTIONED). Makes me think that an article written from the
beginner's perspective, but with THIS information, would be quite
helpful.

If you have any suggestions for how I can improve my article at
http://www.pobox.com/~skeet/csharp/threads I'd be keen to improve it.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Hi Doug:

The thread cannot be interrupted until it blocks (ThreadState =
WaitSleepJoin).

--
Scott
http://www.OdeToCode.com/

On Fri, 8 Oct 2004 21:04:27 -0500, "Doug Thews"
<do*******@remo veme.ddconsult. com> wrote:

Maybe I missed this in your article (but I don't think so), but ... Is there
a reason that a ThreadInterrupt edException does not get raised in a worker
thread if that worker thread just loops without having a Thread.Sleep
command somewhere in the worker thread's loop (even if the Thread is marked
for background before it's started)?

I would've thought that a Sleep wasn't necessary when marking it as
IsBackground before starting it, but until I put at least a Thread.Sleep(0)
(thus giving up at least that timeslice within the loop), my
Thread.Interru pt() from the main thread never generates an exception within
the try...catch clause of my worker thread that surrounds the loop.