En el libro
"La era electromagnética: trabajo, amor y vida, cuando los robots gobiernan el mundo", Robin Hanson analiza brevemente la degradación del programa:
El software fue diseñado originalmente para un conjunto de tareas, herramientas y situaciones. Pero está cambiando lentamente para hacer frente a un flujo constante de nuevas tareas, herramientas y situaciones. Tal software se vuelve más complejo, frágil, es más difícil hacer cambios útiles (Lehman y Biledy, 1985) 1 . Al final, es mejor comenzar de nuevo y escribir desde cero nuevos subsistemas y, a veces, sistemas completamente nuevos.
Estoy seguro de que es verdad. Como regla general, la adaptación competente del software a las nuevas condiciones requiere más tiempo y esfuerzo que escribir un nuevo software desde cero. A los programadores no les gusta admitir esto, pero la evidencia es obvia. Hay varios ejemplos bien conocidos en proyectos de código abierto.
Multiproceso Firefox
Mozilla Firefox inicialmente ejecutó todas las tareas en un solo proceso. Con el lanzamiento de
Google Chrome, quedó claro que un modelo multiproceso mejora la seguridad y el rendimiento. Los desarrolladores de Mozilla pronto comenzaron a planificar cómo implementar el multiprocesamiento en Firefox. Eso fue en 2007.
Casi diez años después, Mozilla finalmente
lanzó el Firefox multiproceso a la audiencia masiva . Este retraso no vino en absoluto por falta de deseo. Mozilla tiene desarrolladores talentosos y motivados. Sin embargo, Chrome se escribió desde cero en mucho menos tiempo del que le tomó a Firefox cambiar. Hay dos razones principales para esto:
- Volver a convertir una arquitectura de un solo proceso en una de múltiples procesos implica muchos pequeños cambios. Algunas llamadas a funciones deben ser reemplazadas por comunicaciones entre procesos. El estado general debe estar envuelto en mutexes. Las cachés y las bases de datos locales deben admitir el acceso concurrente.
- Firefox debe mantener la compatibilidad con las extensiones existentes (o forzar a los desarrolladores a actualizarlas). Chrome creó una API para extensiones desde cero sin tales restricciones.
Pero la situación es aún peor. Las restricciones se contradicen entre sí: debe reconstruir la arquitectura interna, pero dejar las API públicas casi sin cambios. No es de extrañar que Mozilla haya tardado diez años en hacer esto.
Apache orientado a eventos
Apache httpd « ». 80,
accept() fork().
read() write() . ,
close() exit().
, … . , . : 1995 . Apache , . ,
10 000 . « » 1000 1000 . , . .
,
Nginx .
Slowloris.
Nginx 2007 , . Nginx Apache httpd .
event Apache 2.2 2005 . . , , mod_php. 2012 , Apache 2.4 (MPM) . ,
prefork MPM-, Nginx. Apache / . MPM httpd
2.
CPython GIL
Python — . , ( , ) . Python : .
GIL.
:
CPython — , . , CPython . ( GIL , ).
GIL . Python . GIL , . . GIL — . CPython, , , Google, Microsoft Intel,
GIL .
, . , , , , .
, . , . , .
1. « : ». , -. . , .
↑2. , httpd, , . .
↑