Cuál es la forma correcta de esperar una finalización de subproceso y mantener mi aplicación en buen estado

Question

En realidad estoy usando este código y funciona bien, pero me pregunto si es la forma correcta.

while WaitForSingleObject(MyThread.Handle, 0) = WAIT_TIMEOUT do 
    Application.ProcessMessages; 

    ShowMessage('i am done'); 

Answer 1

Calling Application.ProcessMessages se considera generalmente un olor código. Deje que su hilo principal permanezca inactivo si no tiene nada que hacer.

Si dirige una empresa y necesita que uno de sus trabajadores corra a la tienda y compre algunos de los suministros que tanto necesita, ¿podría caminar por la puerta hasta que regrese, o preferiría sentarse en su oficina y descanse y espérelo, y descubra que los suministros están aquí porque lo oye entrar por la puerta? De cualquier manera, tomará la misma cantidad de tiempo, pero la primera forma te desgastará las piernas.

De manera similar, en lugar de tener su UI mirando el hilo, haga que el hilo informe a la IU. Una forma de hacerlo es hacer que el subproceso use PostMessage para enviar un mensaje personalizado al formulario que lo lanzó una vez que finaliza, y poner un controlador de mensajes en el formulario para responderlo.

Answer 2

Parece correcto (si es correcto significa que hace el trabajo). Lo que cambiaría es esperar un poco más de tiempo (50 ms se ve bien para mantener la aplicación en buen estado) sin consumir CPU.

while WaitForSingleObject(MyThread.Handle, 50) = WAIT_TIMEOUT do 
    Application.ProcessMessages; 
ShowMessage('i am done'); 

Seguro que hay otras maneras de hacerlo ... > < broma pero por lo general se deba a uno de los principales principios de la ingeniería:

si funciona, no lo toques! </joke >

Answer 3

Aunque se ve bien, como jachguate usaría un valor de tiempo de espera mayor que 0 también. Si usa WaitForSingleObject(MyThread.Handle, 100), el hilo principal esperará un poco más, consumiendo menos ciclos de CPU.
Sin embargo, una mejor solución sería el uso de mensajes. Su aplicación inicia el hilo y luego pone todos los controles en modo deshabilitado. Luego, el subproceso se ejecuta y, cuando termina, use SendMessage o PostMessage en la ventana principal para notificarle que el subproceso se ha vuelto a realizar. Entonces su aplicación simplemente habilitará cada control (y cualquier otra cosa) nuevamente. Esto tiene la ventaja de que mantiene vivo el bucle de mensajes "natural" para la aplicación, en lugar de ejecutar su propio bucle de mensajes con esta solución.
Desafortunadamente, el método de mensaje tiene un inconveniente: si el hilo se cuelga, no se enviará ningún mensaje, por lo que un plan de respaldo sería práctico. Por ejemplo, agregando un control de temporizador a su forma principal que comprueba cada segundo si el hilo aún está activo. Si no, también activaría el formulario nuevamente, deshabilitándose nuevamente.

Answer 4

Estoy de acuerdo con la observación de Mason Wheeler, es mejor dejar el hilo principal para hacer su trabajo, pero sugeriría utilizar el evento OnTerminate en el hilo. Es más 'Delphi natural' y la lógica interna hace el bit PostMessage para ti. Como TThread no es un componente, no puede verlo en el inspector de objetos y tiene que escribir y adjuntar un manejador de eventos usted mismo. Se llama (¡en el hilo principal!) Después de que el hilo ha finalizado/terminado.

Answer 5

La clase VCL TThread tiene su propio método WaitFor() que bombea la cola de mensajes principal internamente cuando se le llama en el contexto del hilo principal:

MyThread.WaitFor; 
ShowMessage('i am done');