Usar un semáforo en lugar del ciclo while. ¿Esto es bueno o malo?

Question

Tengo un proceso que se ejecuta en su propio hilo y puede iniciarse/detenerse sin bloqueo. Eventualmente, esto irá a un servicio de Windows, pero estoy configurando esto en una aplicación de consola por ahora hasta que esté completamente desarrollado.

Después de la llamada a Inicio(), quiero que el hilo del programa principal se bloquee hasta que se presione Ctrl-C. Sé que esto funcionará:

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 
    } 

} 

Sin embargo, creo que el indicador y el valor de suspensión arbitrario son molestos. Sé que el costo de la CPU es prácticamente 0 en el ciclo while, pero prefiero tener un bloque "difícil" que se libera tan pronto como finaliza el controlador Ctrl-C. Ideé el siguiente, usando un semáforo para bloquear hasta que se haga el manejador anónima Ctrl-C:

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 

} 

¿Es un mal diseño? ¿Es excesivo? ¿Es peligroso?

EDIT:

también puedo conectar AppDomain.CurrentDomain.UnhandledException de la siguiente manera:

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

editar el segundo:

Debo señalar que es fundamental que la Se llama al método Stop() al salir. @Adam Ralph tiene un patrón perfectamente bueno para una consola/servicio híbrido, pero no tenía esta información al responder la Q.

Answer 1

Tenemos un requisito similar en algunas de nuestras aplicaciones. Son servicios de Windows, pero para la depuración a menudo queremos ejecutarlos como aplicaciones de consola. Además, usualmente codificamos aplicaciones nuevas como servicios de Windows desde el principio, pero a menudo no queremos tener que ejecutarlas como servicio hasta más adelante, una vez que hemos probado el concepto, etc.

Este es el patrón que uso: -

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

Contar el hilo a dormir infinitamente podría parecer ineficiente, pero esto es sólo para los escenarios de depuración y el hilo redundante cuesta ningún tiempo de CPU, sólo algunas de memoria (alrededor de 1 MB), que se compone sobre todo de la espacio de pila asignado a la secuencia. El proceso aún puede salir con Ctrl + C o al cerrar la ventana de comandos.

- EDITAR -

Si encuentra que service.Dispose() no se está llamando cuando se pulsa Ctrl + C (es decir, un aborto ocurre grosero) y la llamada a Dispose() es crucial, entonces supongo que se podría hacer de forma explícita este modo: -

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

Tenga en cuenta que Stop() debe encapsularse en Dispose().