Componente BackgroundWorker en servicios

Question

Sé que BackgroundWorker no se debe utilizar en Servicios de Windows, pero ¿alguien podría tener una buena referencia en línea explicando por qué?

Answer 1

BackgroundWorker se basa en que se está configurando SynchronizationContext para que funcione. Realmente está destinado y diseñado específicamente para trabajar con el código de UI.

Normalmente es mejor en un servicio autogestionar sus hilos, ya que no hay problemas de sincronización de IU. Usar la API de subprocesos (o la API de tareas de .NET 4) es una opción mucho mejor aquí.

Answer 2

He utilizado BackgroundWorker en servicios de Windows muchas veces sin ningún efecto negativo. Si bien su uso de SynchronizationContext puede ser innecesario, no he observado que cause problemas o un rendimiento deficiente.

Answer 3

Bueno, está bien usar un BGW en un servicio, simplemente no hace nada especialmente útil. Su razón de ser es su capacidad para generar los eventos ProgressChanged y RunWorkerCompleted en un hilo específico. Hacer que el código se ejecute en un subproceso específico es algo muy trivial. No puede simplemente insertar una llamada en el hilo mientras está ejecutando el código. Eso causa horribles problemas de reentrada. El hilo debe estar 'inactivo', en un estado donde el código de inyección no causa problemas.

Tener un hilo en un estado inactivo es una condición bastante antinatural. Utiliza hilos para ejecutar el código, no para que ellos giren ociosamente sus talones. Sin embargo, esta es la forma en que funciona un hilo de interfaz de usuario. Pasa el 99% de su tiempo en el ciclo de mensajes, esperando que Windows le diga que haga algo. Un clic de botón, una solicitud de pintura, una pulsación de teclado, ese tipo de cosas. Mientras está dentro del bucle de mensaje, de hecho está inactivo. Un muy buen momento para ejecutar el código inyectado.

que es lo que Winforms 'Control.Begin/Invoke y WPF's Dispatcher.Begin/Invoke do. Ponen un delegado en una cola, la cola se vacía y los delegados se ejecutan por el bucle de mensajes. Las clases WindowsFormsSynchronizationContext y DispatcherSynchronizationContext son los proveedores de sincronización que los utilizan. Winforms y WPF reemplazan SynchronizationContext.Current con una instancia de ellos. Que a su vez es usado por BGW para plantear los eventos. Lo que los hace funcionar en el hilo de UI. Lo que le permite actualizar los componentes de la interfaz de usuario que no son seguros para subprocesos a partir de un subproceso de trabajo.

Probablemente pueda ver hacia dónde se dirige, un servicio no usa ninguno. El proveedor de sincronización predeterminado no sincroniza nada. Simplemente utiliza un subproceso de subprocesos para llamar a la devolución de llamada de envío o publicación. Que es lo que sucederá cuando uses BGW en un servicio. Ahora realmente no tiene sentido tener estos eventos. También podría dejar que el controlador DoWork llame directamente a los métodos de gestión de eventos. Después de todo, el hilo en el que se ejecuta DoWork también es otro hilo de subprocesamiento.

Bueno, no hay daño real, aparte de hacerlo un poco más lento.