[pyar] Bloqueo de Deferreds, deferToThread en Twisted y threads en Python, no los entiendo :(

[Alejandro J. Cura]

2011/10/14 Emiliano Dalla Verde Marcozzi <edvm en member.fsf.org>:
> Mis preguntas son:
> 1) Puedo lograr el mismo efecto que 'deferToThread' pero usando solo
> Deferreds ? si es asi, en que estoy
> metiendo la pata ?

No. Punto.

Vamos de nuevo: el modelo de twisted es "asincrónico", o sea:
multitarea cooperativa. Tenés funciones tuyas que hacen algo, pero
tardan poquito y devuelven el control al reactor de twisted, y este se
va a encargar en algún otro momento de volver a llamar a tus otras
funciones, que probablemente pusiste como callbacks en un deferred.
Por eso, deferToThread levanta un thread (para correr la función
sincrónica que le pasás), pero *devuelve inmediatamente* un deferred.
Cuando la función sincrónica tuya termine, el thread que levantó
deferToThread le va a avisar al reactor que tiene que llamar al
callback del deferred que devolvió. (o al errback, si tu función
sincrónica termino con una excepción).

> 2) Me surge la duda de que si los threads en Python son 'secuenciales' por
> el bloqueador GIL de python,
> como funciona pues entonces esto de que al usar deferToThread el sleep(10)
> de la tarea parece 'mandarse'
> en 'background' no bloqueandome el resto de las tareas y no asi usando los
> deferreds ? (posiblemente porque
> los este usando mal?) Me refiero a que da la "sensacion" (que palabra esta
> :P) de que se ejecutan en paralelo
> con deferToThread, como es este tema ?

Estás usando los deferreds mal, si.

> 3) Tengo de oido que usar threads es una mala idea, esto es asi con
> deferToThread?

Como toda herramienta, los threads pueden ser bien usados o mal
usados, no son malos en si.
El mayor problema que le veo a los threads es la incertidumbre que te
da el estado compartido, lo que hace que debuguear algunos problemas
sea de difícil a imposible.
Además, cuando estás haciendo un servidor que atiende miles de
conexiones simultáneas no son la mejor herramienta por un tema de
performance, y de ahí viene la propuesta de twisted de aprovechar
mejor el CPU usando multitarea cooperativa.
Sin embargo, la mayoría de las bibliotecas están hechas para funcionar
en forma sincrónica, por eso es que existe el deferToThread, para
adaptar código sincrónico al modelo asincrónico de twisted.

> 4) {orque existen los threads en Python, en el caso de que se ejecuten
> secuencialmente uno luego del otro por esto del GIL ?

Porque el GIL aplica sobre la ejecución de bytecodes de python, y se
suelta en determinadas ocasiones, por ejemplo: "potentially blocking
or long-running operations, such as I/O, image processing, and NumPy
number crunching, happen outside the GIL".
http://wiki.python.org/moin/GlobalInterpreterLock
En todos esos casos (y algunos más) el GIL no aplica, y el código de
los threads se ejecuta en paralelo.

saludos,
-- 
alecu