Rodrigo Kumpera Weblog

Fico realmente desapontado quando vejo noticias como essa. Quando pessoas supostamente esclarecidas tomam decisões incrivelmente estúpidas. Usar threads nativas porém sincronizando o acesso ao interpretador é aviltante. Por favor, se é para ter threads, que seja para valer, não repetir a mesma tentativa fracassada do python. Não quer suportá-las ótimo, também acho uma péssima abstração, mas então tenha suporte de primeira classe a processos.

Agora o problema todo não se a resume a green-threads são naturalmente ruim, eu até já falei anteriormente sobre isso, mas a questão é garantir que todas threads executem apenas código gerenciado ou código nativo. Essa garantia é suficiente para permitir um sistema escalável é livre dos problemas habituais. Tudo bem que a interface nativa fica muito mais complicada, não é mais um wrapper para o código externo e sim um protocolo de IPC.

Espero pelo menos que esse tipo de discussão sirva para alertar do fato que threading é um mecanismo complicado demais para ser efetivamente utilizado, enquanto troca de mensagens entre processos leves é um paradigma igualmente poderoso com garantias de segurança muito maiores. Quando não existe memória compartilhada e necessidade de locking, concorrência é um problema resolvido localmente por cada processo/ator envolvido. Protocolos são criados e definidos que representam de maneira muito mais clara e lógica o que seria de outra maneira representada por uma estrutura de dados compartilhada e seus monitores.

Enfim, enquanto se discutir o assunto, ainda existe esperança, mesmo que decisões muito erradas sejam tomadas. Não é uma questão simplesmente de nos preparar para um futuro com sistemas com muitos núcleos, mas sim facilitar a construção de software muito mais seguro e confiável. As provas e evidencias estão por toda parte, ao alcance de todos dispostos a abrir os olhos para o futuro.