No livro
“A Era Eletromagnética: Trabalho, Amor e Vida, Quando os Robôs Governam o Mundo”, Robin Hanson discute brevemente a degradação do programa:
O software foi originalmente projetado para um conjunto de tarefas, ferramentas e situações. Mas está mudando lentamente para lidar com um fluxo constante de novas tarefas, ferramentas e situações. Esse software se torna mais complexo, frágil, é mais difícil fazer alterações úteis nele (Lehman e Biledy, 1985) 1 . No final, é melhor começar tudo de novo e escrever do zero novos subsistemas e, às vezes, sistemas completamente novos.
Estou certo de que é verdade. Como regra, a adaptação competente do software a novas condições leva mais tempo e esforço do que escrever um novo software a partir do zero. Os programadores não gostam de admitir isso, mas a evidência é óbvia. Existem vários exemplos conhecidos em projetos de código aberto.
Multiprocesso Firefox
O Mozilla Firefox inicialmente executou todas as tarefas em um processo. Com o lançamento do
Google Chrome, ficou claro que um modelo de múltiplos processos melhora a segurança e o desempenho. Os desenvolvedores da Mozilla logo começaram a planejar como implementar o multiprocessamento no Firefox. Isso foi em 2007.
Quase dez anos depois, a Mozilla finalmente
lançou o Firefox multiprocesso para o público em massa . Esse atraso não veio da falta de desejo. A Mozilla possui desenvolvedores talentosos e motivados. No entanto, o Chrome foi escrito do zero em muito menos tempo do que o Firefox levou para mudar. Há duas razões principais para isso:
- A transformação de uma arquitetura de processo único em uma de processo múltiplo envolve muitas pequenas alterações. Algumas chamadas de função precisam ser substituídas por comunicações entre processos. O estado geral precisa ser envolto em mutexes. Os caches e bancos de dados locais devem oferecer suporte ao acesso simultâneo.
- O Firefox deve manter a compatibilidade com extensões existentes (ou forçar os desenvolvedores a atualizá-las). O Chrome criou uma API para extensões do zero, sem essas restrições.
Mas a situação é ainda pior. As restrições se contradizem: você precisa reconstruir a arquitetura interna, mas deixa as APIs públicas praticamente inalteradas. Não admira que a Mozilla tenha levado dez anos para fazer isso.
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, , . .
↑