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

[Laura Santiago de la Cal]

La función terminate la tengo habilitada ya que si la pongo fuera del slot me termina el hilo perfectamente, asi que ese no puede ser el problemaRespecto a que matar hilos así derepente es mala práctica normalmente ya lo sé, pero en este caso es lo que deseo hacer ya que una vez que yo los mate me preocuparé de dejar el sistema en el estado que yo deseo, asi que por eso no hay problema.El problema es ¿cómo le mato si en un tiempo determinado no ha terminado sin bloquear la cpu con un wait()?
- Hilo conversación -- YoHola, explico lo que busco.
Tengo 2 jugadores, estos jugadores no los programo yo y entonces no sé lo que pone dentro de su código, cada uno de estos dos jugadores será un hilo de mi programa.Lo que quiero es que si el programa que contenga el jugador 1 (o el 2) tarda más de 5 segundos en ejecutarse entero matarlo, pero si tarda por ejemplo 2 segundos mi programa principal no se quede bloqueada durante otros 3 segundos sino que continue con lo siguiente.En pseudocódigo sería algo así
iniciar temporizador;jugador1->jugar;si jugador1 ha acabado o temporizador==fin    jugador->terminate;iniciar temporizadorjugador2->jugar;si jugador2 ha acabado o temporizador==fin    jugador->terminate;
Es decir, quiero que el jugador2 juegue siempre despues del jugador1, pero quiero que si el jugador1 tarda mucho en acabar se le pase su turno y sea el turno del jugador2...
Es una especie de seguridad ya que no sé que contienen los hilos que ejecuto porque son de usuarios externos, pero en ningún caso quiero hacer un sleep(5) en mi programa, porque busco que sea lo más rápido posible, y si el jugador1 tardara solo 1 segundo en hacer su operación sería inconcedible que el programa principal estuviera otros 4 esperando
A ver si alguien sabe si se puede o no hacer algo similar.
- Yo intentando explicarme
> > 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
- Respuestas> 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.


_________________________________________________________________
Internet Explorer 8 más sencillo y seguro ¡Descárgatelo gratis!
http://events.es.msn.com/noticias/internet-explorer-8/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-devel-es/attachments/20090819/e815275f/attachment-0001.htm