4

I need to preform a time intensive task on two-four different servers.

The number of servers can vary.

I need to preform the same task on each machine at roughly the same time otherwise it quadruples the time this process takes.

So far I've been able to come up with this:

public partial class Form_main : Form
{
    list<string> vms = new list<string>;
    ///Fill in vms...
    private void startTest()
    {
        ///prevents GUI from hanging
        ThreadPool.QueueUserWorkItem(new WaitCallback(runTests));
    }
    pirvate void runTests()
    {
        ///Some setup stuff (~1 min)
        foreach(string vm in vms)
        {
            ThreadPool.QueueUserWorkItem(new WaitCallback(testProcedure), new object[] {vm});
        }
    }
}

This works for running everything at once but the problem is that if the GUI is killed the threads do not get killed along with it. I imagine that it is killing the runTests thread but is not killing the testProcedures threads.

How can I make it so that the testProcedures threads get killed on the closing of the GUI?

loopback128
  • 312
  • 4
  • 10
  • 2
    When you close the GUI is `Application.Run(...)` running to completion and exiting the `static void Main(string[] args)` method? The background threads won't be auto killed till all forground threads are done. Either `Main` is not exiting or you are creating foreground threads somewhere else that you are not showing. – Scott Chamberlain Oct 22 '13 at 19:47
  • 2
    As opposed to [aborting](http://stackoverflow.com/a/1560567/533120), you should exit threads cooperatively (i.e. devise a mechanism so you can "signal" to the thread that it should stop gracefully at the next opportune moment). And consider using [tasks](http://msdn.microsoft.com/en-us/library/ff963549.aspx) (and their cancellation tokens) instead of "naked" threads. – Branko Dimitrijevic Oct 22 '13 at 20:00

1 Answers1

1

You can call Environment.Exit method in your OnFormClosed handler of your main form.

Andrew Savinykh
  • 25,351
  • 17
  • 103
  • 158
  • 1
    This is obscuring the problem. If you have other foreground threads running then you should determine if you really want foreground threads; perhaps they should be background threads. If `Application.Run` isn't ending then something else is keeping the UI alive, and you should determine what's going on there and resolve it. This is hiding an underlying problem, rather than fixing it. – Servy Oct 22 '13 at 19:59
  • 1
    You are right and wrong. Yes, it is possible that there may be a problem. But maybe not. In .net 1.0 for example all thread would not be killed automatically on the main thread exit. Often it's too expensive to investigate irrelevant problems that can be reliably dealt with an one-liner solution. In the situation described we know that we DO want to kill them all, and that's what we are doing? Are there better ways to do this? Perhaps. Would it consume less time even in the long run? Hardly. – Andrew Savinykh Oct 22 '13 at 20:37
  • 1
    If you have investigated specifically what is holding the application alive and have confirmed that there is no alternative way of ending the application more gracefully, then sure, this can be an occasionally valid last resort. The question makes it clear that this isn't the case, as he doesn't know what's causing the application to be kept alive. This is an entirely *inappropriate* solution if you don't know what the underlying issue is, as you can have significant problems killing an application like this. Suggesting the OP not even *try* to diagnose the problem is simply unacceptable. – Servy Oct 22 '13 at 20:42
  • @Servy I totally agree that it's a good idea to try and diagnose the problem. – Andrew Savinykh Oct 22 '13 at 20:57
  • What is unacceptable is for the GUI thread to get blocked, unable to reach it's ExitProcess(), or whatever, call because it's waiting unnecessarily for other threads. Setting 'Thread.IsBackground = true' should work for Thread descendants. If there is no overriding reason for the other threads to perform any termination actions, it'a a waste of time and effort to write code to explicitly terminate them - let the OS do it - it's very good at it, much simpler and more reliable than any user code. – Martin James Oct 22 '13 at 23:52