¿Cómo trabaja un Timer?
 

Buenas tardes,

Me gustaría saber exactamente cómo trabaja un timer, y en qué momento genera un evento. Para ello, he creado un formulario con 4 botones y un timer (salta cada segundo, y cuando salta, escribe una linea con el texto "Timer!" en el cuadro de texto). Situando el ratón sobre los botones de la izquierda, vemos el código asociado a cada uno de ellos.

Botón 3: Entiendo perfectamente lo que sucede al apretarlo. Se activa el timer y el thread principal queda libre. Al quedar libre, recibe los eventos del timer y los ejecuta. Cuando vuelves a apretar el botón 3, el timer se desactiva y no llega ningún evento más. Aquí llega la primera duda: ¿quién genera esos evento? Tengo claro quien los atiende, el thread principal, pero no quién los genera.

Botón 11: Entiendo medianamente lo que sucede al apretarlo. Se activa el timer, pero el thread principal se queda dormido durante 5 segundos. Tras ello, se desactiva el timer. Todo ello sin dar opción al thread principal de ejecutar nada más. ¿El resultado? No se escribe ninguna linea en el cuadro de texto. De este comporamiento, deduzco que, aunque han pasado más de un segundo desde que se activo el timer, puesto que el thread principal no ha estado libre, no se ha generado ningún evento del timer. Y como no se ha generado ningún evento del timer, no se ha atendido nigún evento y no se ha escrito nada. Por lo tanto, deduzco que es el thread principal quien él mismo, en su "tiempo libre", genera los eventos del timer que él mismo atenderá. ¿Esto es realmente así?

Botón 1: Siguiendo mi teoría, supongo que, en el momento en que hacemos ProcessMessage, el thread principal queda libre y genera un evento del timer, y lo atiende. Una vez (generados y) estudiados todos los eventos pendientes, se desactiva el timer. Por lo tanto, supongo que es el thread principal quien genera, en su "tiempo libre" los eventos del timer. Y además, genera 1 y sólo 1, tan pronto como puede, aunque en realidad correspondería generar 5, ya que han pasado 5 segundos. ¿Alguien sabe qué sucedió con los otros 4 eventos? ¿Por qué no se generaron?

Botón 2: Siguiendo mi reoría, entiendo por qué, durante los primeros 5 segundos, no llega ningún evento. Simplemente, el thread principal no los generó, y en consecuencia no los atendió, ya que estaba dormido. Sin embargo, en cuanto despierta, supongo yo que genera 2 eventos, ya que, en su tiempo libre, los atiende escribiendo dos lineas en el cuadro de texto!! ¿Por qué 2 tan seguidos y no 1, y al cabo de un segundo, otro más? Entiendo que el evento lo genera el thread principal tan pronto como queda libre, al darse cuenta de que el timer lleva activo 5 segundos y que debería haber saltado al segundo 1. Por lo tanto, se genera un evento y se atiende. Pero, el segundo evento, ¿en qué momento se generó y debido a qué? llega, con total seguridad, en emnos de un segundo!

Bien amigos, ya estána aquí todas las preguntas que tenía. Si alguien es capaz de dar respuesta fehaciente, confirmando quién genera los eventos de los timers, y bajo qué condiciones (¿1 evento? ¿2 eventos?), con lo que entenderemos el por qué de los distintos comportamientos, será de gran ayuda. Al menos, para mí, aunque espero que también para otros muchos.

Saludos y gracias a todos.

Hola rcuevas.

No pude correr tu ejecutable ya que me pide la vcl100.bpl que no dispongo, lástima no pusiste los fuentes...

Pero de todos modos, el componente TTimer encapsula las funciones de temporización de Windows API simplificando el uso de SetTimer, KillTimer y TimerProc, así como también el procesamiento de los mensajes WM_TIMER.

La información detallada de dichas funciones API podes encontrarla aquí: Timers

Saludos :)

Recuerda que esto es un foro de ayuda, no olvides nuestra guía de estilo, muestra tu código fuente para que te puedan ayudar. Eso de enviar solamente un ejecutable queda feo, además de peligroso. Gracias por tu colaboración.

Pd: He borrado el adjunto del ejecutable.

Buenos días,

Tienes razón Casimiro. Yo no lo había pensado, pero cualquier payaso puede venir aquí y añadir un ejecutable malicioso.
Adjunto el código fuente del programa.

Ecfisa, he estado leyendo la documentación que propones. Pero sólo con esa documentación no soy capaz de resolver las dudas que tengo. A ver si ahora, con el código fuente adjunto, eres capaz de compilar y ejecutar el programa.


Saludos y gracias a todos.

Hola rcuevas.

No puedo correr tu código por que tengo una versión inferior de C++ Builder (6.0), pero mirándolo define las siguientes acciones:

Entonces mi pregunta es: ¿ Cuales son los pasos exáctos que das durante la ejecución de tu programa y que generan tu duda ?

Pregunto por que por ejemplo: Un click sobre Button1 activa el Timer, pero se desactiva automáticamente cuando el cursor del mouse sale de ese control para realizar cualquier otra acción...


Eso es cierto pero si sospecho intencionalidad lo hará sólo una vez, por que sin dudar ni un segundo lo baneo hasta por su IP ;).
Y, aunque siempre controlo minuciosamente y aislo cualquier ejecutable que descargo antes de ejecutarlo, no puedo dejar de destacar lo acertado de la acción de Casimiro ^\||/.

Saludos :)

Buenas tardes ecfisa,

Eso no es del todo cierto, ya que cuando el cursor sale del botón, lo único que sucede es que se limpia la memo donde escribo lo que hace ese botón, pero no modifico ninguna propiedad del timer.

Y fíjate que hay 2 memos. Una en la que escribo al situar el cursor sobre alguno de los 4 botones. La otra, en la que escribo en cada evento del timer.

Es difícil entender mi duda si no puedes compilar el ejecutable. El lunes lo subiré de nuevo, si es que Casimio me lo permite.

Saludos y gracias.

Hola rcuevas.

Tenes toda la razón, me confundí reacomodando el código en el block de notas.

Por favor no subas el ejecutable nuevamente.

Voy a revisar otra vez el código fuente con mas detenimiento. Aunque dame algo de tiempo por que debo agregar los eventos OnMouseEnter y OnMouseLeave ya que en C++ Builder 6 no están implementados.

Saludos :)

Hola de nuevo ecfisa,

No hace falta que implementes esos eventos.
Yo los había implementado para que vieseis, en cada botón, lo que estaba implementado.
Pero ahora ya tienes el codigo fuente!

Simplemente implementa los eventos onclick de los botones y el evento ontimer del timer.
Una vez hecho eso, ejecuta el programa y evalúa los resultados, teniendo en cuenta lo que digo en mi primer mensaje.

Saludos.

Ok, el asunto es que intentando entender esto estas mezclando varias cosas.

Primero que todo, Sleep no tiene relacion directa con un timer. De hecho, funciona aunque lo uses en codigo "normal".

Todo arranca por entender en primer lugar como funciona una app "visual". A diferencia del entendimiento basico de como funciona un programa ("se ejecuta todo de arriba-abajo paso a paso") una app visual trabaje en un:

https://en.wikipedia.org/wiki/Event_loop

Nota como existen varias formas de hacer eso, y varian por plataformas, entornos y todo eso.

Basicamente algo asi como:

Código Delphi [-]
while True do
begin
  //De alguna manera, procesar eventos tipo GUI aqui

 //De alguna manera, saber que debo salir de aqui cuando todo termine
end;

Es por eso que se puede bloquear la GUI. Todo corre un ciclo que NO TIENE GARANTIAS de tiempos de ejecución (ie: cada paso puede ejecutar arbitrariamente un proceso demorado). Eso es lo que uno entiende por "la gui corre un un thread", lo cual es casi siempre asi.

Un timer por lo tanto (dependiendo de su implementación) es simplemente un "pulsador" de eventos, que no necesariamente garantiza que cada X tiempo va a invocar su handler -recuerda, puede correr sobre el event loop!-.

Todo este preludio para que entiendas que un timer es una idea muy simple conceptualmente:

Código Delphi [-]
while True do
begin
  //De alguna manera, procesar eventos tipo GUI aqui
 
  if timers.tiempoacumulado >= timers.tiempodefinido do
  begin
  //De alguna manera, ejecutar procesar los eventos
 end;
 //De alguna manera, saber que debo salir de aqui cuando todo termine
end;

Como este implementado el timer, varia. La documentación mejor que encontre es:

http://msdn.microsoft.com/en-us/magazine/cc164015.aspx

La relacion con sleep se da por:

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
Y eso se logra mediante un Interrup, que es como un "parar a las malas" y por eso se desaconseja su uso si se quiere tener un programa multi-hilo o que no bloquee -ya que un sleep de estos puede ser problematico ya que puede crear un deadlock o problemas de sincronizacion, como aclaran los links que te puse-. Esto es lo importante de porque no hay que mezclar el sleep con el timer = Puedes "pausar" usando el timer!

El punto: INTERRUMPIR el programa/thread no es una tarea de un timer. Mas bien, es la de ejecutar cada X un evento(s). Es *ideal* nunca bloquear un thread, ya que interfieres con el event loop.

Eso responde "Como trabaja un timer". Lo demas es "Como esta implementado un timer basado en el API de mensajes de windows", y el resto de los docs "Y como se basan los otros tipos de timer".

Hola mamcx,

Entiendo el concepto del bucle de los eventos. Aún así, muchas gracias por la explicación.

Intentaré resumir las dudas con las siguientes preguntar:
- Quien genera y encola los eventos del timer? Qué thread? El thread principal u otro thread? Yo apuesto por el thread principal.
- Cuando genera y encola el evento del timer? Yo supongo que cuando está libre y se percata de que ya ha pasado el tiempo establecido.
- Cuántos eventos genera y encola cuando se da cuenta de que ha llegado la hora? 1? O tantos como hibiesen sido generados si no hubiese estado ocupado? Yo creo que debería generar sólo uno.
- Una vez generado y encolado un evento, cuanto tarda en generar y encolar un nuevo evento? Yo creo que, desde que generó el ultimo evento, debería esperar el tiempo establecido en el timer, por lo menos.

Compila y ejecuta la aplicación. Veras los comportamientos q describo en mi mensaje inicial.

Saludos y gracias.

Mucha de la respuesta esta en:

http://stackoverflow.com/questions/1...-threading-app

Basicamente: El API de windows es quien controla todo. TTimer es solo un wraper. Este es creado en el thread ppal. Los links que te pase responden el resto.

Recordando un tema similar, busqué "TTimer+funcionamiento site:www.clubdelphi.com" en Google, lo cual me llevó a este hilo de los foros:

http://www.clubdelphi.com/foros/showthread.php?t=73908

No se trata de ninguna explicación magistral, pero de algo puede servir. Aplica de igual forma a Delphi y a C++Builder.

Buenos días Al González,

Tras leer tus indicaciones, tengo claro que el sistema operativo es quien genera los eventos del timer. Algo que no sabía.
Pero sigo sin tener claro cuándo los genera, porque, según lo que veo en mi aplicación, mientras el proceso está dormido mediante un sleep, el sistema operativo sólo genera un evento, cuando le hubiese dado tiempo a generar 5!! Si los eventos los ha de generar el sistema operativo cada segundo, y nuestro programa ha pasado 5 segundos dormidos, es lógico que durante esos 5 segundos no haya tratado ningún evento, pero no es lógico que el sistema operativo, que no ha estado durmiendo, no haya generado 5 eventos...

Bien, seguiremos investigando.

Gracias por tu ayuda.

Si has leido los links que te pase? Porque todas las preguntas ya estan respondidas a este punto.

No sabes ingles?

mamcx te ha querido decir que el sleep duerme el hilo, es decir, el bucle de mensajes, por lo que el S.O. no puede generar el evento, ya que el hilo simplemente no procesa el mensaje. Si quieres evitar ese efecto, debes tener otro hilo, con su bucle de mensajes, que responda...


Saludos.

Que es exactamente lo que pasa, recuerda, es un INTERRUP y eso aplica a todo el thread. Por eso, el OS no puede enviar nada al thread, esta pausado! asi que mientras esta pausado, este "ignora" al thread.

Lo cual esta explicado en los links, por ejemplo:

Asi que no le des vueltas. Todo esta sucediendo tal como se ha explicado y no hay ningun comportamiento "anomalo" ni inesperado. Recuerda que al usar el API del OS, estas cooperando y siguiendo con su forma de hacer las cosas, y una app GUI igual esta construida sobre el mismo, asi que no es extraño que trabajen al unisono si se reutilizan aspectos de la misma API subyacente.