Using a semaphore instead of while loop. Is this good or bad?

Question

I have a process that runs in it's own thread and can be started/stopped without blocking. This will eventually go into a Windows service, but I am setting this up in a console app for now until it is fully fleshed out.

After the call to Start(), I want the main program thread to block until Ctrl-C is pressed. I know that this will work:

public static void Main(string[] args)
{
    bool keepGoing = true;

    var service = new Service();

    System.Console.TreatControlCAsInput = false;

    System.Console.CancelKeyPress += delegate(object sender, ConsoleCancelEventArgs e)
    {
        e.Cancel = true;
        service.Stop();
        keepGoing = false; // Break the while loop below
    };

    service.Start();

    while( keepGoing )
    {
        Thread.Sleep(100); // 100 is arbitrary
    }

}

However, I find the flag and arbitrary sleep value bothersome. I know that the CPU cost is practically 0 in the while loop, but I'd rather have a "hard" block that releases as soon as the Ctrl-C handler is done. I devised the below, using a semaphore to block until the anonymous Ctrl-C handler is done:

public static void Main(string[] args)
{
    var service = new Service();

    var s = new Semaphore(1, 1);

    System.Console.TreatControlCAsInput = false;

    System.Console.CancelKeyPress += delegate(object sender, ConsoleCancelEventArgs e)
    {
        e.Cancel = true;
        service.Stop();
        s.Release(); // This will allow the program to conclude below
    };

    service.Start();

    s.WaitOne(); // This will not block
    s.WaitOne(); // This will block w/o CPU usage until the sempahore is released

}

Is this a bad design? Is it overkill? Is it dangerous?

EDIT:

I also hook up AppDomain.CurrentDomain.UnhandledException as follows:

AppDomain.CurrentDomain.UnhandledException += delegate {
  service.Stop();
  s.Release();
};

EDIT the 2nd:

I should note that it is crucial that the Stop() method get called on exit. @Adam Ralph has a perfectly good pattern for a hybrid console/service, but didn't have this information when answering the Q.

Answer 1

We have a similar requirement in a few of our apps. They are Windows services, but for debugging we often want to run them as console apps. Moreover, we usually code new apps as Windows services fairly early on but often don't want to have to actually run them as a service until later, once we've proved the concept, etc.

This is the pattern we use:-

using (var service = new Service())
{
    if (Environment.UserInterActive)
    {
        service.Start();
        Thread.Sleep(Timeout.Infinite);
    }
    else
    {
        ServiceBase.Run(service);
    }
}

Telling the thread to sleep infinitely might seem inefficient, but this is only for debugging scenarios and the redundant thread costs no CPU time, just some memory (about 1MB), which is mostly composed of the stack space allocated to the thread. The process can still be exited with Ctrl+C or by closing the command window.

-- EDIT --

If you find that service.Dispose() is not being called when Ctrl+C is pressed (i.e. a rude abort happens) and the call to Dispose() is crucial, then I guess you could explicitly do this like so:-

using (var service = new Service())
{
    if (Environment.UserInterActive)
    {
        Console.CancelKeyPress += (sender, e) => service.Dispose();
        service.Start();
        Thread.Sleep(Timeout.Infinite);
    }
    else
    {
        ServiceBase.Run(service);
    }
}

Note that Stop() should be encapsulated in Dispose().