Stopping threads when the app is closed

[Juha Nieminen]

I have created an application using Visual Studio 2008 Express, in
C++.NET, using the gui designer.

The app consists of one single form, and what it does is that the GUI
can be used to set up options and parameters as well as the input data,
and then a "run" button can be clicked. This launches a thread which
performs heavy-duty calculations on that data (which may take minutes or
more). The GUI thread uses a timer to update itself (show progress,
etc). In this mode it also has a "stop" button which tells the
calculation thread to stop immediately.

This all works just fine. There's one big problem, though: If I close
the app without stopping the calculations, the calculations thread will
not stop until it's done. This means that although the app window has
been closed, the app itself will be running in the background for as
long as it takes for the calculations, and the only way to stop it is to
kill it from the process manager.

The solution would seem to be simple: When closing the app is
requested, make it stop the calculations thread. However, I have no idea
how this can be done. The form has a "is going to close" event trigger
which sounds like could work, but it doesn't: That function doesn't get
called until the calculation thread ends, even if the app window is
closed. There's also a "was closed" event, but it doesn't work either.

How to properly catch that the user is closing the app, so that I can
make the calculation thread stop at that point immediately?

 

[David Lowndes]

This all works just fine. There's one big problem, though: If I close

the app without stopping the calculations, the calculations thread will
not stop until it's done.

So the solution is to tell the calculation thread to close - which
means that you have to write this calculation thread so that it
regularly checks a flag that signals it to close down.

Dave

 

[Ben Voigt [C++ MVP]]

So the solution is to tell the calculation thread to close - which
means that you have to write this calculation thread so that it
regularly checks a flag that signals it to close down.

When the app is closing it's perfectly ok to just call Process.Exit

 

[SvenC]

Hi Ben,

When the app is closing it's perfectly ok to just call Process.Exit

Wouldn't that just kill the worker threads in the middle of the work
they are doing which might lead to all kinds of corruptions if they
e.g. are in the middle of saving some of their state?

 

[r norman]

Hi Ben,


Wouldn't that just kill the worker threads in the middle of the work
they are doing which might lead to all kinds of corruptions if they
e.g. are in the middle of saving some of their state?

That depends on what you mean by "corruptions" or "saving their
state". If the app closes, presumably it no longer cares about any
corruption in the calculation. If the state has to be saved to be
reused when the app restarts, then you must ensure that everything
closes cleanly. Otherwise, you can just kill the whole thing.

 

[Doug Harrison [MVP]]

I have created an application using Visual Studio 2008 Express, in
C++.NET, using the gui designer.

The app consists of one single form, and what it does is that the GUI
can be used to set up options and parameters as well as the input data,
and then a "run" button can be clicked. This launches a thread which
performs heavy-duty calculations on that data (which may take minutes or
more). The GUI thread uses a timer to update itself (show progress,
etc). In this mode it also has a "stop" button which tells the
calculation thread to stop immediately.

This all works just fine. There's one big problem, though: If I close
the app without stopping the calculations, the calculations thread will
not stop until it's done. This means that although the app window has
been closed, the app itself will be running in the background for as
long as it takes for the calculations, and the only way to stop it is to
kill it from the process manager.

If you're talking about a .NET program, there is a difference between
"foreground" and "background" threads. As long as it is running, a
foreground thread keeps the process alive, while a background thread does
not do this. So, if your secondary thread is a foreground thread, that
would explain your observation. There is no such distinction in native
code.

The solution would seem to be simple: When closing the app is
requested, make it stop the calculations thread. However, I have no idea
how this can be done. The form has a "is going to close" event trigger
which sounds like could work, but it doesn't: That function doesn't get
called until the calculation thread ends, even if the app window is
closed. There's also a "was closed" event, but it doesn't work either.

How to properly catch that the user is closing the app, so that I can
make the calculation thread stop at that point immediately?

In general, it is best for the primary thread to join with all the
secondary threads before exiting. To do it cleanly, you have to ask the
secondary threads to exit. I wrote this for native threading, but the
principles at least should carry over to managed code. See Q2 and on
(unless you're doing MFC, in which case, definitely read Q1 as well):

http://members.cox.net/doug_web/threads.htm

 

[Juha Nieminen]

David Lowndes kirjoitti:

So the solution is to tell the calculation thread to close

I explained in my original post that I'm trying to do that, but it's
not working: I can't tell the calculation thread to close since I don't
know how to hook to the app termination. Can you explain to me how it
should be done?

 

[Juha Nieminen]

David Lowndes kirjoitti:

So the solution is to tell the calculation thread to close

I explained in my original post that I'm trying to do that, but it's
not working: I can't tell the calculation thread to close since I don't
know how to hook to the app termination. Can you explain to me how it
should be done?