(Otros) problemas con la memoria y (otras) soluciones

Alguien en programming.reddit hizo una pregunta de esas difíciles: ¿Cómo manejar en un programa en C los casos en los que la memoria se agota? Y digo que es una de esas preguntas difíciles porque depende del tipo de software que estás haciendo, de su criticidad y del nivel requerido de robustez. Ya se sabe, el difícil compromiso de la gestión de errores críticos.

Y como se ve en las respuestas de los redditenses no sólo depende de nuestro sistema, sino de detalles de implementación de más abajo, como suele ser usual en los casos no del todo raros en los que las abstracciones que usamos comienzan a flaquear. En este caso se habla del comportamiento de Linux (el kernel) a la hora de tratar la falta de memoria, que por defecto usa una estrategia optimista que deja reservar (pero no usar, claro) más memoria de la disponible. No obstante este comportamiento se puede cambiar a uno un poco más controlable a través del parámetro overcommit_memory, que se introdujo no hace tanto... El comportamiento por defecto es llamar al OOM Killer que es un método tan drástico como poco predecible. Todo esto esta muy bien explicado en When Linux Runs Out of Memory que vi referenciado por aquí en tiempos de mayor intensidad técnica :)

Además en las respuestas se apunta a un libro online de los que vienen bien cuando las condiciones son más extremas de lo usual: Small Memory Software. Patterns for systems with limited memory. Apuntado en éste mi del.icio.us particular.

(El título es "(Otros) problemas con la memoria y (otras) soluciones " porque no hace mucho escribí Problemas de memoria (y algunas soluciones), sobre el cuello de botella que supone la gestión de memoria sobre todo en sistemas multicore)

"(Otros) problemas con la memoria y (otras) soluciones" en barrapunto

¿Testeo o corrección?

Andaba yo descubriendo otro blog, el de Andrew Koenig, cuando, a raíz de dos post suyos seguidos (uno de aserciones contra excepciones y otro sobre la depuración) he reparado en el tema... últimamente se hace mucho hincapié en el desarrollo guiado por pruebas, pero según se puede ver en el segundo post, hay veces que las pruebas, e incluso el uso, no son garantía de corrección.

Por eso es tan importante que las pruebas sean realistas. Por eso es tan importante extraer información del sistema en todas la etapas del ciclo de vida. Por eso es tan importante un buen sistema de registro del sistema. Pero sobre todo, por eso es importante pensar bien antes de codificar.

También me ha recordado uno esos principios de desarrollo polémicos: Los fallos, cuanto antes mejor (Fail Fast). Es uno de los principios en el diseño de Erlang. Como dice Joe Armstrong en una entrevista reciente:

La filosofía de Erlang fue siempre construir sistemas con un montón de procesadores baratos y permitir que fallen. No prevenimos el fallo; vivimos con él y recuperamos el sistema cuando ocurren.

Hay que recordar que se trata de fallos irrecuperables, no de casos raros dentro de la lógica del programa. Es mejor dejar claro un error fatal que tratar de continuar cuando no se puede y que se pierda el rastro de lo sucedido...

Por supuesto el título es falaz, debería haber sido Testeo y corrección y todos contentos, pero espero que se me permita el recurso :)

¿Testeo o corrección? en barrapunto

¿Postel o Dracón?

La primera vez que leí sobre la ley de Postel: "Sé conservador con lo que envias, liberal con lo que recibes"(*) me pareció tan filosóficamente interesante que intenté escribir una entrada al respecto, pero no supe, porque no tengo el gen gurú necesario para ello. Por eso, no está mal recurrir a los gurús de verdad, que sean ellos los que digan parte de lo que le ronda a uno por la cabeza. El caso es que en una semana dos blogstars de esto de la programación y la tecnología han comentado algo relacionado, así que les cedo la palabra, claro (cada una de las entradas da mucho más de si, pero claro, para eso está enlazadas, para que se lean ;)):

• Jeff Atwood en Coding Horror habla de en "JavaScript and HTML: Forgiveness by Default" de como siendo tolerante a fallos se crea un ecosistema más robusto. En sus palabras: "el perdón por defecto es un requisito imprescindible para una adopción a gran escala tan masiva como la de la web". Eso si, no habla del precio que hay que pagar, porque una implementación tolerante a fallos, en general es más compleja. Hay que preguntarse ¿qué hacer con los errores?
• Sam Ruby en "Different Drummer" habla del diseño de HTML5 y se pregunta si ganarán los que siguen a Dracón o a Postel. Él se decanta por Postel, claro. El resto del post muy interesante también. Muy gurú. Muy Sam Ruby :)
  Por cierto que habla de Silverlight y dice que también es Draconiano. En eso no me voy a meter, le cedo la palabra a otro que sabe más que yo (no voy a llamarle gurú porque igual no le gusta): Yogur Griego: "Silverlight ¿el imperio contraataca?"
• Hablando de gurús y aunque no es nuevo, no me resisto a enlazar otra vez "Objects Have Failed" de Richard P. Gabriel debido a que uno de sus argumentos para la irrelevancia de los objetos es (exagerando creo, tiene algún recurso literario, quizás por eso me gusta más...):

  En el viejo mundo nos centrábamos en la eficiencia, la limitación de recursos, el rendimiento, los programas monolíticos, los sistemas aislados, los programas hechos por un sólo autor y las aproximaciones matemáticas. En el nuevo mundo pasarán a primer plano la robustez, la flexibilidad, la adaptación, los sistemas distribuidos, los programas de múltiples autores y las metáforas biológicas de la computación.

(*)Otras veces nombrado como "Sé conservador con lo que haces, liberal con lo que aceptas de otros". El enunciado es susceptible de ser políticamente interpretable más aún en esta segunda encarnación del principio. En este caso yo creo que es más bien interpretable desde el punto de vista de la ética. Como referencia se puede leer lo que dice Tim Berners-Lee acerca de esto y de una frase (que fué durante un tiempo firma mía) acerca del funcionamiento descentralizado "We have no kings or presidents. We believe in rough consensus and running code". Eso si, con grandes influencias de Unitarismo universalista, una religión más o menos buenrollista, si es que eso es posible...

"¿Postel o Dracón?" en barrapunto