[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