Dalam buku
"Era Elektromagnetik: Pekerjaan, Cinta, dan Kehidupan, Ketika Robot Mengatur Dunia," Robin Hanson secara singkat membahas degradasi program:
Perangkat lunak ini awalnya dirancang untuk satu set tugas, alat, dan situasi. Tetapi perlahan-lahan berubah untuk menghadapi aliran tugas, alat, dan situasi baru yang konstan. Perangkat lunak seperti itu menjadi lebih kompleks, rapuh, lebih sulit untuk membuat perubahan yang berguna di dalamnya (Lehman dan Biledy, 1985) 1 . Pada akhirnya, lebih baik memulai dari awal dan menulis dari awal subsistem baru, dan terkadang sistem yang sama sekali baru.
Saya yakin itu benar. Sebagai aturan, adaptasi yang kompeten dari perangkat lunak ke kondisi baru membutuhkan lebih banyak waktu dan usaha daripada menulis perangkat lunak baru dari awal. Programmer tidak suka mengakui hal ini, tetapi buktinya jelas. Ada beberapa contoh terkenal dalam proyek sumber terbuka.
Firefox multiproses
Mozilla Firefox awalnya menjalankan semua tugas dalam satu proses. Dengan rilis
Google Chrome, menjadi jelas bahwa model multi-proses meningkatkan keamanan dan kinerja. Pengembang Mozilla segera mulai merencanakan cara menerapkan multiprosesing di Firefox. Itu pada 2007.
Hampir sepuluh tahun kemudian, Mozilla akhirnya
merilis multiproses Firefox ke khalayak ramai . Penundaan ini tidak datang sama sekali karena kurangnya keinginan. Mozilla memiliki pengembang yang berbakat dan termotivasi. Namun, Chrome ditulis dari awal dalam waktu yang jauh lebih singkat daripada yang dibutuhkan Firefox untuk berubah. Ada dua alasan utama untuk ini:
- Mengubah arsitektur proses tunggal menjadi proses multi melibatkan banyak perubahan kecil. Beberapa panggilan fungsi perlu diganti dengan komunikasi antarproses. Keadaan umum perlu dibungkus dalam mutex. Tembolok dan basis data lokal harus mendukung akses bersamaan.
- Firefox harus menjaga kompatibilitas dengan ekstensi yang ada (atau memaksa pengembang untuk memperbaruinya). Chrome membuat API untuk ekstensi dari awal tanpa batasan seperti itu.
Tetapi situasinya bahkan lebih buruk. Pembatasan saling bertentangan: Anda perlu membangun kembali arsitektur internal, tetapi biarkan API publik hampir tidak berubah. Tidak heran Mozilla membutuhkan waktu sepuluh tahun untuk melakukan ini.
Apache Berorientasi Kejadian
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, , . .
↑