Un vistazo al interior de memcached

Leo en El valle del Viento Helado un artículo acerca de la arquitectura interna de memcached. memcached es un sistema de cachés genéricas muy usado en aplicaciones web. En el artículo se repasa tanto la elección de libevent como sistema de gestión de eventos sobre descriptores de fichero, el uso de funciones de entrada/salida no bloqueantes y sobre todo una gestión de memoria basada en un slab allocator. Contiene además enlaces con más información sobre el tema aunque como siempre la información última está en el código fuente.

La misma entrada y más comentarios en Un vistazo al interior de memcached en barrapunto

¿Demasiadas capas de abstracción?

Vuelve otra vez uno de mis temas favoritos, el de la complejidad inherente y creciente de los sistemas de información, tratado esta vez por Ian Lance Taylor en Layered Programming. Me permito citraducir un párrafo, un poco al vuelo:

Cada vez es más difícil ser un experto en sistemas. Cuando aprendí a programar, era posible entender todo tu programa, desde el código fuente hasta el código máquina. Sin embargo, cuando escribes una aplicación moderna en Ajax esto es se vuelve imposible. Hay demasiados intérpretes diferentes. Hay demasiado código ejecutándolo. Ni arreglarlo con un nuevo nivel base por encima del procesador (el navegador(?)) ayudaría. Todo esto nos conduce a una pérdida de rendimiento a veces notable y, lo que es a veces más importante, una perdida de seguridad.

No podemos volver atrás. Pero me pregunto si podremos confluir en un modelo de programación que pueda ser comprendido en su totalidad en todas sus capas. O si las cosas simplemente van a ser más complicadas cada vez.[0]

Y no sólo me permito la cita, sino que además respondo :) Y mi respuesta (que me perdonen Alvin y Heidi Toffler) es pesimista, en el sentido de que no hay vuelta atrás al idílico pasado en el era posible comprender completa, local y globalmente un sistema. La tendencia es la de más lenguajes, más plataformas y más capas, incluso dentro de los propios procesadores y nunca la contraria.

Pero no es por los ejemplos concretos que vemos a diario por que creo que esto va a seguir siendo así, sino por el trasfondo. Los sistemas de información van evolucionando unos sobre otros y rara vez se da el caso de retroceso de una paso evolutivo exitoso[1], lo que se conoce como Ley (o hipótesis) de Dollo[2] en evolución biológica, que nos vuelve a dar un ejemplo de uno de mis juegos mentales preferidos, el paralelismo entre sistemas biológicos e informáticos [3]. A quien mejor he leído referirse a este paralelismo es a Richard P. Gabriel en su Objects Have Failed y que explora de nuevo en Design Beyond Human Abilities (pdf)

No obstante, a pesar de la tendencia natural, creo que uno de los deberes de un diseñador, arquitecto, desarrollador, programador o comoquierallamársele es contener en lo posible la complejidad del sistema global [4]


[0] El primer comentario apunta, yo creo que con acierto, a "The Law of Leaky Abstractions" de Spolsky.
[1] Existen sistemas que tienen diversos enfoques o paradigmas, que yo asimilaría a distintas ramas evolutivas. La tesis de Dollo aplicada a los sistemas informáticos sería válida sólo en el progreso de una rama evolutiva. En diversas ramas evolutivas se pueden dar una tendencia y la contraria, claro...
[2] Hablé hace tiempo de esta ley en La ley de Dollo y los sistemas informáticos
[3] Otro ejemplo de dicho paralelismo podría ser el del monocultivo, del que escribí hace ya mucho en Los peligros del monocultivo y Los peligros del monocultivo (de nuevo)
[4] Conviene recordar un par de mantras clásicos: "Controlar la complejidad es la esencia de la programación de ordenadores" de Brian Kernighan y "Cualquier problema de computación puede ser resuelto con un nuevo nivel de indirección, excepto si el problema es que hay demasiados niveles de indirección" de David Wheeler (La exactitud de esta última es dudosa, pero me gusta esa versión)

La misma entrada y más comentarios en ¿Demasiadas capas de abstracción? en barrapunto

Notas sobre errores fatales y portabilidad

Es escasa y dispersa la información que he encontrado acerca de la gestión de errores fatales en distintos sistemas operativos y lo que afecta al funcionamiento de los programas sobre ellos. Así que voy a juntar lo que he ido recopilando en una sola entrada. Puede ser un poco batiburrillo, pero igual le es de utilidad a alguien... (Para mi seguro, que así no pierdo los enlaces). Ordenadas de general a específico[1]:

• En ANSI C existe signal que permite cambiar la gestión este tipo eventos, entre los que se encuentran SIGSEGV, violación de segmento y SIGFPE, error aritmético. No obstante, por desgracia, su comportamiento en programas con más de un thread no está especificado. Además por si fuese poco ANSI tampoco especifica el handler por defecto, es decir, qué es lo que pasa si salta una señal de ese tipo.


• De hecho, de los que he probado, en windows con la librería de C del VisualStudio al menos, las señales funcionan por thread y en linux es global por proceso...


• En POSIX si que se define el comportamiento por defecto de las señales. En concreto SIGSEGV y SIGFPE abortan el proceso completo . Se pueden ver los comportamientos por defecto de las distintas señales en POSIX en la documentación de <signal.h> del OpenGroup. Además, POSIX(R) recomienda pasarse a sigaction (que sólo es POSIX(R), no ANSI).


• Windows NT no genera señal de violación de segmento, pero se le puede instalar handler


• En win32 un error fatal se gestiona como una excepción estructurada (SHE) que en C++ se mapea a un excepción normal[2]. Además, una excepción estructurada no capturada, por defecto, supone la muerte del thread en el que se produce, pero no del proceso global .


• Existe una forma de sobrescribir este comportamiento por defecto y es SetUnhandledExceptionFilter. Recomiendan en Nynaeve[3] no hacer cosas demasiado complicadas en el manejador, como parece lógico.


• En un artículo de DeveloperWorks comentan un modo de convertir señales en excepciones pero que es un hack completamente erróneo: C++ exception-handling tricks for Linux porque da a entender que se puede replicar el comportamiento por defecto de Windows. Sin embargo, como se puede leer en "Program Error Signals" de la documentación de la glibc:

  La acción por defecto de todas estas señales es terminar el proceso. Si se bloquean o ignoran estas señales o se establece un handler que retorna normalmente, tu programa cascará espantosamente en el momento en que suceda la señal no ser que(*) haya sido generada a través de raise o kill en lugar de un error real.

  cosa que he podido comprobar con el código de DW tratando de ignorar una violación de segmento.


• En resumen, lo más juicioso (y homogéneo entre plataformas) sería parar el proceso completo en caso de uno de estos errores y tratar de informar lo más completamente posible del error. En caso de win32 habría que forzar el fin del proceso, ya que no es la acción por defecto[4].

[1]El orden es de mayor a menor, de general a específico. Debería ser obvio para un programador: a igualdad de condiciones, se debería usar lo que funcione en el estándar más aceptado y amplio ¿por qué limitar el ámbito de aplicación? Primero, buscar en ANSI, y si la funcionalidad no está elegir conscientemente una solución más específica. En el fondo para mi no es más que una consecuencia de la ley de Postel sobre el el código: "Cuanto más estricto (más estándar) es lo que escribes, más aumentarás la interoperabilidad". Puede parecer una obviedad, pero en esas pequeñas microdecisiones de los programadores no es nada extraño usar extensiones del estándar sin necesidad. Y en caso de necesidad se puede echar mano de librerías libres, muchas de ellas con un alto nivel de portabilidad.

[2]Pongo en cursiva normal porque entra la duda si en esos casos, de tan bajo nivel, una excepción, que se confunde con excepciones de de otro tipo, es lo más clarificador para el usuario-programador, máxime cuando el C++ estándar no posee excepciones para gestionar estos casos...

[3]Un blog que he descubierto hace poco... interesante. Además sobre el mismo tema: Beware of custom unhandled exception filters in DLLs y You might be using unhandled exception filters without even knowing it

[4]Cabe preguntarse porque se permite la ejecución del proceso en un caso tan excepcional... habida cuenta además de que una excepción no capturada de de C++ provoca, por defecto el fin del proceso... En este caso está sin duda justificado el Fail Fast: lo que hay que hacer es arreglar el programa, no dejarlo seguir...

(*)Me despisté al traducir. Gracias a Javier Noval por leerse los enlaces y hacerme notar el error ;)

Notas sobre errores fatales y portabilidad en barrapunto