Exposicion

[Hernan Martinez Foffani]

> > > Sobre el futuro se podría comentar el objetivo Python3000,
> > > del "python stackless" y de los continuadores, etc.
> > > Esto último quizás sería demasiado.
> >
> > ¿Podrías hablar un poco de los continuadores o dar algún enlace?
> > He leido lo del stackless Python y los nombra, pero no encontré más
> > información.
>
> Cierto, yo sólo he encontrado referencias sobre la implementación
> internas, pero nada sobre continuadores y demás.


Tismer, el desarrollador que creo el Stackless Python, anuncio hace
poco una nueva versión. SP nunca estuvo ausente de las polémicas. De
hecho, GvR nunca quiso incorporar las modificaciones de Tismer en el
core.

Las dos críticas principales que se le hacia a SP eran:
- aprovechando que había liberado al core de Python de la pila de C,
  el autor original comenzo a incluir demasiadas funcionalidades
  nuevas que no habían sido discutidas en la comunidad.
- todo el código de SP está lleno de microptimizaciones.
- cada nueva versión de Python implicaba muchos cambios en SP,
  aumentando las posibilidades de incluir nuevos fallos.
- imposiblidad de emular esas funcionalidades en Jython.
- a pesar de que varios genios de Python Labs analizaron el SP,
  el unico que entendía el código era Tismer.

La nueva versión de SP es mucho mas reducida, abandona la petensión
de incorporarse al core presentándose a partir de ahora como un
paquete que se "agrega" a la distribución de Python. El mantenimiento
se reduce al minimo al ser SP muy independiente de la distribucion de
Python.

Incluye algunas rutinas en lenguaje ensamblador por lo que será
necesario un port para cada plataforma. Tismer mantendrá las versiones
de Intel.

Las funcionalidades que implementa SP son: microhilos y corutinas.
Hace poco hizo algunas mediciones y contó 1.000.000 de cambios de
contexto en 0,6 segundos en un AMD Athlon. En otra medición 100.000
hilos simultáneos ocuparon 80 MB (800 bytes por hilo.)


En cuanto a las preguntas específicas, trataré de dar una pequeña
explicación rápida basada en memoria y en "cositas" que me quedaron
guardadas por ahí. ¡Ala los profesores de C.C. que leen la lista!
¡Mejoren o corrijan estas explicaciones! :-)

continuación: la continuación de una computación es lo que sigue a
esa computacion expresado como funcion del resultado de esa
computacion.
[ ¿por qué traducen "continuation" como continuador? yo lo entiendo
como estado mas que como mecanismo. lo pregunto por saber no por
polemizar ]
Conceptualmente imaginen a una continuación como un lugar en un
programa. No solo una etiqueta o una dirección, es todo el estado
MAS el código que resta ejecutar.
En términos prácticos es como un breakpoint en un debugger. Cuando
un Sistema Operativo hace un cambio de contexto entre diferentes
procesos, internamente está resguardando la continuación del
proceso suspendido y recuperando la del proceso reestablecido.

Junto con definiciones, comandos, y otros, la continuación
(uso la traducción a la que estoy acostumbrado) es una abstracción
que todos los lenguajes de programación poseen. La diferencia es
si es explícita ("disponible" para el programador) o no. Y aún así
dependerá de "cuanto" se implemente. A no ser que alguien quiera
crear un lenguaje donde el programador pueda hacer una vuelta
(rollback) a cualquier estado anterior del proceso, no es
necesario implementar un mecanismo de continuaciones completo.

La pareja setjmp/longjmp sería una implementación de continuaciones
explícitas en C si setjmp() resguardara, y longjmp() restableciera,
la pila interna de C en forma completa. La primera versión de SP
reescribía todo el corazón de Python para que ninguna porción del
estado de ejecución estuviera en la pila de C. La nueva versión de
SP modifica la pila interna de C (de ahí la necesidad de usar
ensamblador) haciéndole "creer" al corazón de Python que sigue
usando dicha pila.

Las continuaciones explicitas como mecanismo en un lenguaje son
muy poderosas. Es la abstracción básica con la que se puede
construir corutinas, hilos, objetos, generadores y todo tipo de
gestionador de excepciones. Es el GOTO en los bucles :-)

corutinas: pieza de código con nombre que puede ser reiniciada
por otra corutina y viceversa.

¡Si un lenguaje dispone de continuaciones explícitas es posible
implementar las facilidades mencionadas dentro del mismo
lenguaje! Pero tienen similares limitaciones que el GOTO, si
algun desarrollador decide programar un servidor multihilos
utilizando las continuaciones que le brinda el lenguaje, es muy
probable que el resultado final sea inmantenible.

En mi opinión fuera del ámbito de la investigación en la práctica
un programador nunca usa continuaciones para implementar un
algoritmo. Bastarían con construcciones como corutinas, hilos,
generadores y manejo de excepciones.

Saludos,
-Hernán.