[pyar] Duda sobre el uso de hilos

[Roberto Alsina]

On Saturday 12 June 2010 22:12:45 Matías Waterloo wrote:
> El 12 de junio de 2010 20:15, Roberto Alsina <ralsina en netmanagers.com.ar>
> escribió:
> 
> On Saturday 12 June 2010 19:47:45 Matías Waterloo wrote:
>  >  Muchas gracias a todos por contestar, estoy desarrollando una
>  > aplicación gui, que se podría llegar a correr en diferentes maquinas al
>  > mismo tiempo. Se trata de una aplicacion para una remisería y
>  > necesitaría una forma de ir controlando el tiempo tanto para q me avise
>  > cuando un pedido esta retrasado un tiempo "x" (eso creo q es bastante
>  > sencillo) como también que me avise cuando una reserva esta próxima en
>  > el tiempo (eso creo q sería un poco mas complejo). Ahora voy a
>  > investigar el "sched" a ver si me sirve.
> 
> Casi todos los frameworks gráficos tienen algún objeto timer que dispara un
>  callback, no?
> 
> Capaz lo que vaya a decir ahora es la visión de alguien que no tiene mucha
> experiencia pràctica en el campo. Estoy estudiando ingenieria en sistemas
> de información y algo que no enseñan es que no es conveniente que la gui
> se encargue de la lógica de la aplicación, por lo tanto, trato de evitar
> usar algo por el estilo.

Estás programando una aplicación gráfica? Entonces tenes un event loop, y te 
lo provee el toolkit. 

Si vas a considerar al event loop "gui" y decidir cuando se ejecuta un 
callback "lógica", vas a tener "lógica" en la "gui" cada vez que el usuario 
apriete un botón ;-)

De todas formas, los timers normalmente no son objetos gráficos, no son 
visibles, y (por lo menos en el caso de QTimer) funcionan aún en aplicaciones 
no-gráficas, siempre que tengas un event loop corriendo.

Pensar en poner un thread corriendo sched [1] para evitar poner un timer me 
parece medio raro, pero a cada cual su idea.


[1] In multi-threaded environments, the scheduler class has limitations with 
respect to thread-safety, inability to insert a new task before the one 
currently pending in a running scheduler, and holding up the main thread until 
the event queue is empty. Instead, the preferred approach is to use the 
threading.Timer class instead.