Dans le livre
«L'âge électromagnétique: travail, amour et vie, lorsque les robots gouvernent le monde», Robin Hanson discute brièvement de la dégradation du programme:
Le logiciel a été initialement conçu pour un ensemble de tâches, d'outils et de situations. Mais il évolue lentement pour faire face à un flux constant de nouvelles tâches, outils et situations. De tels logiciels deviennent plus complexes, fragiles, il est plus difficile d'y apporter des modifications utiles (Lehman et Biledy, 1985) 1 . Au final, il vaut mieux tout recommencer et écrire à partir de zéro de nouveaux sous-systèmes, et parfois des systèmes complètement nouveaux.
Je suis sûr que c'est vrai. En règle générale, l'adaptation compétente d'un logiciel à de nouvelles conditions prend plus de temps et d'efforts que l'écriture d'un nouveau logiciel à partir de zéro. Les programmeurs n'aiment pas l'admettre, mais les preuves sont évidentes. Il existe plusieurs exemples bien connus dans les projets open source.
Firefox multiprocessus
Mozilla Firefox a initialement exécuté toutes les tâches en un seul processus. Avec la sortie de
Google Chrome, il est devenu clair qu'un modèle multi-processus améliore la sécurité et les performances. Les développeurs de Mozilla ont rapidement commencé à planifier comment implémenter le multitraitement dans Firefox. C'était en 2007.
Près de dix ans plus tard, Mozilla a finalement
rendu public le multiprocessus Firefox . Ce retard ne vient pas du tout d'un manque de désir. Mozilla a des développeurs talentueux et motivés. Cependant, Chrome a été écrit à partir de zéro en beaucoup moins de temps qu'il n'a fallu à Firefox pour changer. Il y a deux raisons principales à cela:
- Refaire une architecture mono-processus en une architecture multi-processus implique de nombreux petits changements. Certains appels de fonction doivent être remplacés par des communications interprocessus. L'état général doit être enveloppé de mutex. Les caches et les bases de données locales doivent prendre en charge l'accès simultané.
- Firefox devrait maintenir la compatibilité avec les extensions existantes (ou forcer les développeurs à les mettre à jour). Chrome a créé une API pour les extensions à partir de zéro sans ces restrictions.
Mais la situation est encore pire. Les restrictions se contredisent: vous devez reconstruire l'architecture interne, mais laisser les API publiques presque inchangées. Pas étonnant que Mozilla ait mis dix ans à le faire.
Apache orienté événement
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, , . .
↑