[pyar] Agregar tareas asíncronas por eventos generados de interfaz de usuario

[David Weil]

Buenas!

On 11/29/2017 8:07 PM, Luis Andraschnik wrote:
> Hola David!
>
> Si yo voy a dar una charla PyAr está en el horno ..Podría titularlo 
> "Programemos sin saber" ó "Qué bueno que es Python que hasta yo programo"

Me gusta el segundo nombre para la charla! En serio, esta bueno ver 
python aplicado a cosas reales y que no sean siempre las mismas!
Si no te atreves a una PyConAr primero, buscate un PyDay!!


> Aclarando un poco la diferencia de estrategias: Dado que quiero que la 
> aplicación pueda manejar (leer la temperatura) más de una estufa a la 
> vez y básicamente la mayor parte del tiempo el programa espera durante 
> el polling puedo destinar un proceso para cada estufa con un sleep 
> sincrono  (estrategia 1) ó un único hilo con sleep asíncrono 
> (estrategia 2). Las 2 funcionan pero la segunda es menos costosa en 
> términos de recursos (lo probé haciendo un "top" bajo linux). Ambas 
> estrategias publican en una cola de mensajes de zmq con el topic que 
> es el número de slave (=estufa) + la lectura de temperatura y la hora 
> actual

Muy bien! sin duda, si no hay motivos para no usar la version 
asincrónica, no tiene sentido tener N procesos, que hacen casi nada 
nada, esperando todo el tiempo. A por la estrategia 2 (que además la 
tenés cocinada ya por lo que veo)!


> La aplicación completa (cualquiera de las estrategias) tiene un 
> segundo proceso que subscribe a la cola  y graba en sqlite toda la 
> info para registro y análisis posterior.
> Otro proceso levanta un web server (uso flask), subscribe también a la 
> cola de mensajes para tener todas las lecturas y vía protocolo server 
> sent event envía al browser los datos en tiempo real , y mediante 
> plotly.js grafica la temperatura (live).

Perfecto!

> Todo lo probé y funciona. ahora necesito controlar via interfaz de 
> usuario el inicio y final del proceso de leer los datos de cualquier 
> estufa individualmente sea a través de un schedulling o dando alguna 
> orden directa via POST/GET , pasando el parámetro slave_number , 
> time_polling, datos_del_cultivo, temperatura, hora_inicio, hora_fin.
>
> Lo que se me ocurre es hacer una corrutina que cree las tareas, que 
> esté escuchando en una cola de mensajes atento al topic "inicia" o 
> "parar".

Si, una segunda cola de mensajes, en el otro sentido, no? La verdad que 
nunca usé zmq así.. usé un poco celery y no me gusta demasiado!

Sí, para el control desde la interfaz de usuario haría que haga post 
desde la web con los cambios a realizar.. y el webserver lo mande a la 
cola esa de mensajes nueva..

> Seguidamente detengo la ejecución de las tareas que corresponden a las 
> estufas 1 a 9.
> Básicamente hay una lista de tareas dónde el índice  0 es gen_tasks , 
> y las siguientes son las que leen la temperatura de su correspondiente 
> estufa. El método cancel() hace el trabajo.
Perfecto entonces! El cancel era la solucion y una corrutina extra, 
desde la cual leer los mensajes que entren desde el zmq en la cola en la 
que escribe el browser, para a partir de ahí, generar tareas nuevas!

Muy bueno también que generas los programas con datos simulados!
Si no sabés programar, lo camuflás muy bien!  Felicitaciones!!
Saludos,
dave