[Python-es] Envío de mensajes a múltiples destinos

[Alberto Valverde]

Jesus Cea wrote:
> Antonio Beamud Montero wrote:
> |> De hecho los threads serían muy eficientes, porque solo están
> |> interesados en un socket cada uno y no usan select.
> |
> | Crear y destruir hilos por conexión es muy pesado.. para pequeños
> | sistemas va bien, pero si crecen los requisitos, escala mal..
> 
> En Solaris crear un hilo es muy ligero. Por otro lado, no he dicho que
> se creen cuando llegan conexiones. Puedes usar un "pool".
> 
> Mira Apache 2.2, por ejemplo.
> 
> | ¿Te refieres a que es trivial programar con hilos vs programar un
> | sistema asíncrono (twisted)?
> |
> | Todo depende, yo la mejor combinación la obtuve con twsited (epoll) +
> | hilos (para las tareas que requerian más procedimiento). Con el tiempo,
> | veo más trivial programar asincronamente que con hilos.
> 
> Te pongo un ejemplo: si una peticion requiere que vayas a una base de
> datos, con hilos puedes permitir bloquear ese hilo mientras esperas que
> la base de datos responda. Con Twisted tienes que integrar la
> comunicacion con la base de datos en el framework, so pena de que se te
> bloquee todo mientras "alguien" está esperando por la base de datos.
> 
> Además, puedes usar todos los módulos. Por ejemplo, puedo mandar un
> email con "smtplib" como siempre, sin temer que el rendimiento caiga
> para el resto.
> 
> O, sencillamente, puedo realizar un cálculo matemático muy largo y
> complejo o generar un gráfico que me lleva varios segundos, sin
> penalizar al resto de hilos. Esto no lo puedes hacer en twisted sin que
> tu código ceda el control al framework *explícitamente* cada poco tiempo.
> 
> Lo lamento, pero Twisted no me gusta nada :). Y sí, sé bien que los
> threads no son la panacea. Algún día pondré mis ideas por escrito... :-)

Estoy totalmente de acuerdo con que el paradigma de los hilos es más
natural ya que "es lo suyo", que el sistema operativo se encargue de
gestionar la multitarea y no obligue a las aplicaciones a ceder el
control cooperativamente. Sin embargo, tal y como están las cosas, por
lo menos en linux (no conozco solaris), no es factible tener un número
muy alto de hilos del S.O concurrentes atendiendo a cada conexión, una a
una. Hay un momento en el que se acaba la memoria :)

Entiendo que se busquen soluciones a nivel de aplicación; enrevesadas
algunas (twsited ;) o de hilos ultra-ligeros (erlang, stackless...)

Alberto