In dem Buch „Das elektromagnetische Zeitalter: Arbeit, Liebe und Leben, wenn Roboter die Welt regieren“ diskutiert Robin Hanson kurz die Programmverschlechterung:

Die Software wurde ursprünglich für eine Reihe von Aufgaben, Tools und Situationen entwickelt. Aber es ändert sich langsam, um mit einem ständigen Strom neuer Aufgaben, Werkzeuge und Situationen fertig zu werden. Solche Software wird komplexer, fragiler, es ist schwieriger, nützliche Änderungen daran vorzunehmen (Lehman und Biledy, 1985) ¹ . Am Ende ist es besser, von vorne zu beginnen und neue Subsysteme und manchmal völlig neue Systeme von Grund auf neu zu schreiben.

Ich bin sicher, dass es wahr ist. Eine kompetente Anpassung der Software an neue Bedingungen erfordert in der Regel mehr Zeit und Mühe als das Schreiben neuer Software von Grund auf. Programmierer geben dies nicht gerne zu, aber die Beweise sind offensichtlich. In Open Source-Projekten gibt es mehrere bekannte Beispiele.

Multiprozess-Firefox

Mozilla Firefox führte zunächst alle Aufgaben in einem Prozess aus. Mit der Veröffentlichung von Google Chrome wurde deutlich, dass ein Multiprozessmodell die Sicherheit und Leistung verbessert. Mozilla-Entwickler begannen bald zu planen, wie Multiprocessing in Firefox implementiert werden soll. Das war im Jahr 2007.

Fast zehn Jahre später veröffentlichte Mozilla schließlich den Multiprozess-Firefox für das Massenpublikum . Diese Verzögerung kam überhaupt nicht aus einem Mangel an Verlangen. Mozilla hat talentierte und motivierte Entwickler. Chrome wurde jedoch in viel kürzerer Zeit von Grund auf neu geschrieben, als Firefox zum Ändern benötigte. Dafür gibt es zwei Hauptgründe:

• Das Umwandeln einer Einzelprozessarchitektur in eine Mehrprozessarchitektur erfordert viele kleine Änderungen. Einige Funktionsaufrufe müssen durch Interprozesskommunikation ersetzt werden. Der allgemeine Zustand muss in Mutexe eingeschlossen werden. Caches und lokale Datenbanken müssen den gleichzeitigen Zugriff unterstützen.
  
• Firefox sollte die Kompatibilität mit vorhandenen Erweiterungen beibehalten (oder Entwickler zwingen, diese zu aktualisieren). Chrome hat eine API für Erweiterungen von Grund auf ohne solche Einschränkungen erstellt.

Aber die Situation ist noch schlimmer. Die Einschränkungen widersprechen sich: Sie müssen die interne Architektur neu erstellen, die öffentlichen APIs jedoch nahezu unverändert lassen. Kein Wunder, dass Mozilla dafür zehn Jahre gebraucht hat.

Ereignisorientierter Apache

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².

CPython GIL

Python — . , ( , ) . Python : .

GIL. :

CPython  — , . , CPython . ( GIL , ).

GIL . Python . GIL , . . GIL — . CPython, , , Google, Microsoft Intel, GIL .

, . , , , , . , . , . , .

---

• : ?
  
• : !
  
• :

---

1. « : ». , -. . , . ↑

2. , httpd, , . . ↑