[Kde-devel-es] Matar hilos (QThread) pasado un tiempo sin hacer sleep

José Luis jsanchez at todounix.homeip.net
Wed Aug 19 09:49:51 CEST 2009


Laura Santiago de la Cal wrote:
> Estoy intentando que cada programa no hecho por mi sea un hilo que 
> lanzo yo desde mi programa y controlar el tiempo máximo de ejecución 
> mediante un Qtimer...
> Y aquí está mi problema, por más que miro información por todos lados 
> y hago pruebas no consigo nada.
>
> La última que he probado y no da error en la compilación ni la 
> ejecución es la siguiente:
>
> QTimer *timer = new QTimer(a);
>
> connect( timer, SIGNAL(timeout()), this, SLOT(quit()));
>
> timer->start(2000); //2000=2segundos
>
> a->start();
>
>
> En otra parte del código tengo:
>
>
> public slots:
>
> void quit()
>
> {
>
>   printf("Si imprime esto FUNCIONA\n");
>
>   a->terminate();
>
> }
>
>
> El problema es que no me da error ni nada, pero tampoco funciona, 
> nunca me llega a matar al hilo ni a mostrar el mensaje... ¿alguna idea 
> de qué estoy haciendo mal?
>
> Gracias por vuestra ayuda
Me temo que lo peor que estás haciendo es no leer la documentación de la 
Qt. El método terminate() está desaconsejado por buenas razones (igual 
que cayeron en "deprecated" los métodos stop() y resume() de la clase 
Thread en Java). Probablemente, el problema más difícil de depurar con 
el que haya bregado yo fue por matar threads a lo bestia. Avisada estás.

Por otra parte, leyendo la doc de la Qt 4.5.2 veo que hay un método 
llamado setTerminationEnabled() que habilita/deshabilita el uso de la 
llamada a terminate(). Lo que no me queda claro en la doc es qué estado 
tiene ese miembro estático que permite o no hacer caso inmediatamente a 
terminate(). Lo que sí está claro es que si el estado por defecto es 
'false' no hará ni caso a terminate() así que la llames 100.000 veces 
hasta que lo pongas a 'true'.

Desconozco porqué tienes esas limitaciones en tu programa, pero es muy 
difícil hacer un programa basado en threads que se comporte bien si 
éstos no colaboran un poco. Lo civilizado sería que los threads 
implementaran una clase con la obligación de "cumplir un contrato". 
Nadie más que el thread sabe en qué momento puede pararse, así que el 
hilo principal no debería hacer más que llamar a un método del thread 
que le diga que se pare. Si éste hace caso bien, si no....

Se me ocurren varias maneras de bregar con un thread políticamente 
incorrecto, pero algunas de ellas no serían muy portables y dependen 
mucho de la implementación de los threads en el S.O. subyacente (y la 
implementación de Linux no es para tirar cohetes), tú sabrás si tienes 
necesidad de codificar con la portabilidad en mente. Es posible que 
hubiera soluciones mejores usando procesos en lugar de threads, habría 
que pensarlo.

Saludos
José Luis


More information about the Kde-devel-es mailing list