Estado actual del Stackless

[Francesc Alted]

On Mon, Dec 02, 2002 at 12:28:16PM +0100, Juan David Ibáñez Palomar wrote:
> Chema Cortés wrote:
> 
> >La cosa es que hay dos implementaciones. La antigua no gustaba a Guido por 
> >ser demasiado intrusiva, y ponía en dificultades muchos módulos. El PEP 
> >sobre el tema se cerró por inactivo, y ahí terminó.
>
> Si no me equivoco lo que no le gustaba a Guido no era la
> implementación, era sobre todo que dadas las limitaciones
> de la máquina virtual de Java no seria posible implementar
> stackless en jython (o por lo menos no seria posible con
> un rendimiento aceptable).

Mmmm, esa era una de las razones, pero creo recordar que habia más. En
particular, creo haber leido que la más importante es que Guido pensaba que
la implementación de Stackless era demasiado complicada y prefirió no
incluirla (o sea, la que apuntaba Chema). Además pensaba que las ventajas de
Stackless se irian supliendo con el avance en otros modulos (como el de
multithread).

Más info en estos artículos de David Mertz (uno de ellos incluye una
entrevista con el Tismer):

http://www-106.ibm.com/developerworks/library/l-pyth7.html
http://www-106.ibm.com/developerworks/library/l-pythrd.html

> El que tenia un problema con la implementación era el propio
> desarrollador de stackless, ya que le costaba mucho esfuerzo
> seguir el desarrollo de Python.

Hombre, pues claro. Si tu haces una extensión del core de Python y el Guido
no te la acepta, pues ya vas de culo para toda la vida haciendo portings
para cada versión de Python que salga, por muy "minor" que sea.
Senciallamente, no es factible.

> >La implementación nueva (salida dos días después de haber salido el python 
> >2.2.2) parece menos intrusiva y simple que se basaría en la implementación 
> >multihilo del python. Pero no tiene PEP que la explique, y sólo tiene 
> >implementación para windows. Hay que incluso habla de cambiar el nombre 
> >para diferenciar el desarrollo de la antigua implementación.

No creo que se base en la implementación multihilo de python (por cierto,
donde lo has leido?), como dices, ya que Stackless provee una manera de
simular multiples threads bastante más eficiente que la que viene por
defecto en los S.O. El módulo en cuestión se llama microthreads
(http://willware.net:8080/uthread.html) y haciendo uso de las modificaciones
al core de python que proporciona Stackless puede llegar a crear threads que
hacen el context switch (CS) mucho más rápido y utilizar mucha menos memoria
que los threads convencionales que vienen en los distintos S.O. El
inconveniente es que solo pueden utilizar una única CPU en contra de las
múltiples que pueden utilizar los estándar. Sin embargo, para situaciones en
las que se usan threads sólo para simular una multiplexación de I/O
fácilmente y sin recurrir a técnicas asíncronas va muy bien (ver
http://www.ironport.com/ que está basado en esta tecnologia), de hecho,
mucho, muchísimo mejor que los OS threads.

> >
> >Lo único que saco en claro es que todavía no ha muerto el proyecto; pero 
> >¿habría álguien que pudiera explicar esta nueva implementación del 
> >"stackless"? ¿serán las continuaciones iguales que en la antigua 
> >implementación? ¿habrá pronto versión para otras plataformas?
> >

A mi entender, mo ha muerto básicamente por dos razones:

1.- Hay sistemas comerciales que usan y abusan del Stackless y no lo pueden
dejar morir alegremente.

2.- Y la más importante. Me da la impresión que el Christian Tismer está como
una regadera y que podria preferir dejar otras cosas en la vida antes que a
su criatura.


Yo he probado el Stackless (de hecho estuve bastante excitado con él hace un
par de años) por el tema de microthreads precisamente y va bastante bien.
La lástima es que los conceptos de corutinas sean tan enrevesados que mucha
gente se desanima antes de prestarles la debida atención. Tismer tampoco
ayuda mucho porque no proporciona buena documentación. Se ve que le interesa
más programar que venderse bien. Guido tampoco colabora...

Bueno, ya digo, una lástima porque, en mi opinión, Stackless aporta unos
conceptos muy útiles.

-- 
Francesc Alted                            PGP KeyID:      0x61C8C11F
Scientific applications developer
Public PGP key available: http://www.openlc.org/falted_at_openlc.asc
Key fingerprint = 1518 38FE 3A3D 8BE8 24A0  3E5B 1328 32CC 61C8 C11F