¿Por qué no podemos cambiar el estado de un subproceso de ThreadPool y por qué no necesitamos una bomba de mensajes cuando se usa ShowDialog?

Question

Recientemente, encontré esta situación en la que quería mostrar un formulario en otro hilo (no el hilo principal/IU). Usé un hilo de subprocesos. El formulario alojaba un RCW (para un componente COM). La instanciación del formulario me dio la excepción de que el hilo debe ser una STA. Traté de establecer el estado del departamento como STA. Pero eso tampoco funcionó. Finalmente terminé creando un hilo de manera explícita y eso funcionó (utilicé ShowDialog y no necesito crear una bomba de meesage).

EDIT:

• Sé que threadpool hilos son MTA. Pero, ¿por qué no se puede establecer en STA? Solo curiosidad por esto.
• Otra pregunta que acaba de hacer estallar en mi cabeza: ¿Por qué no requiere una bomba
  mensaje cuando ShowDialog() (a
  pantalla un formulario) se utiliza

Answer 1

El apartamento se selecciona mediante una llamada a CoInitializeEx(). Un hilo en el grupo de subprocesos ya ha hecho esa llamada, cambiando el apartamento después de que la llamada no sea posible.

El hecho de que un grupo de subprocesos elija MTA tiene sentido, después de todo es una cadena de trabajo y no debe ser bloqueada por llamadas a métodos que se deben calcular. La selección de un apartamento de subproceso único tiene el requisito adicional de bombear un bucle de mensaje. Algo que nunca esperarías que hiciera un subproceso de subprocesamiento.

El bucle de mensajes es necesario porque ese es el vehículo que COM utiliza para coordinar una llamada realizada en otro hilo. Esa llamada debe ser "inyectada" en el hilo STA, eso solo es posible si el hilo se encuentra en un estado de reposo conocido. Si no es así, tal llamada causaría problemas importantes de reentrada. Lo cual a veces sucede incluso si el hilo está bombeando el ciclo.

No necesitó bombear un bucle de mensaje usted mismo con Application.Run() porque ShowDialog() inicia su propio bucle de mensaje. Así es como gana la modalidad. Ese bucle anidado sale tan pronto como se cierra el cuadro de diálogo.

Answer 2

Usted no debe confiar en comportamiento específico para subprocesos de grupo de subprocesos. En general, un subproceso en el grupo de subprocesos debería poder ser reemplazado en cualquier momento por el CLR, sin su conocimiento. Los subprocesos del grupo de subprocesos están destinados a ser utilizados con tareas simples, preferiblemente de corta vida.

Si desea tener un control detallado de la configuración de subprocesos, debe crear un subproceso dedicado. Configurar el estado del departamento es un ejemplo perfecto de esto.

---

Además de los motivos teóricos anteriores, hay un problema práctico con lo que está intentando. Hospedar un formulario en un segundo subproceso no funciona (sin mucho trabajo adicional). Los formularios se deben ejecutar en el mismo hilo que la bomba de mensajes; de lo contrario, no recibirán ningún mensaje de Windows y no se actualizarán correctamente.

Puede crear un formulario en un subproceso separado si implementa una bomba de mensajes completa para ese subproceso, pero generalmente es una mejor idea simplemente poner sus elementos de trabajo en subprocesos de fondo y utilizar técnicas de programación asíncronas para mantener su UI hilo receptivo