Por que o JavaScript não suporta multithreading?

É uma decisão deliberada de projeto ou um problema com nossos navegadores atuais que serão corrigidos nas próximas versões?

   

O JavaScript não suporta multiencadeamento porque o intérprete JavaScript no navegador é um único encadeamento (AFAIK). Mesmo o Google Chrome não permite que o JavaScript de uma única página da Web seja executado simultaneamente, porque isso causaria problemas de concorrência em massa nas páginas da Web existentes. Tudo o que o Chrome faz é separar vários componentes (diferentes guias, plug-ins, etc.) em processos separados, mas não consigo imaginar uma única página com mais de um thread JavaScript.

No entanto, você pode usar, como foi sugerido, setTimeout para permitir algum tipo de agendamento e concorrência “falsa”. Isso faz com que o navegador recupere o controle do encadeamento de renderização e inicie o código JavaScript fornecido para setTimeout após o número especificado de milissegundos. Isso é muito útil se você quiser permitir que a viewport (o que você vê) seja atualizada durante a execução de operações. Basta percorrer, por exemplo, coordenadas e atualizar um elemento de acordo com isso, permite que você veja as posições de início e fim e nada entre elas.

Usamos uma biblioteca de abstração em JavaScript que nos permite criar processos e encadeamentos que são todos gerenciados pelo mesmo intérprete de JavaScript. Isso nos permite executar ações da seguinte maneira:

  • Processo A, Thread 1
  • Processo A, Thread 2
  • Processo B, segmento 1
  • Processo A, linha 3
  • Processo A, Thread 4
  • Processo B, Thread 2
  • Pausa no Processo A
  • Processo B, Rosca 3
  • Processo B, Thread 4
  • Processo B, Tópico 5
  • Inicie o processo A
  • Processo A, Thread 5

Isto permite alguma forma de escalonamento e falsificação de paralelismo, iniciando e parando de threads, etc, mas não será multi-threading verdadeiro. Eu não acho que isso será implementado na linguagem em si, já que multi-threading verdadeiro é útil apenas se o navegador puder rodar uma única página multi-thread (ou até mais do que um core), e as dificuldades são muito maiores do que as possibilidades extras.

Para o futuro do JavaScript, veja isto: https://developer.mozilla.org/presentations/xtech2006/javascript/

Tradicionalmente, o JS era destinado a pequenos códigos de execução rápida. Se você tivesse grandes cálculos em andamento, você o faria em um servidor – a ideia de um aplicativo JS + HTML que funcionasse no seu navegador por longos períodos fazendo coisas não triviais era absurda.

Claro, agora nós temos isso. Mas, vai demorar um pouco para os navegadores para recuperar o atraso – a maioria deles foram concebidos em torno de um modelo single-threaded, e mudando isso não é fácil. O Google Gears contorna muitos problemas potenciais ao exigir que a execução em segundo plano seja isolada – sem alterar o DOM (já que não é seguro para thread), nenhum object de access criado pelo thread principal (idem). Embora seja restritivo, esse provavelmente será o design mais prático para o futuro próximo, tanto porque simplifica o design do navegador quanto porque reduz o risco envolvido em permitir que codificadores JS inexperientes mexam em threads …

@marcio :

Por que isso é uma razão para não implementar o multi-threading em Javascript? Os programadores podem fazer o que quiserem com as ferramentas que possuem.

Então, não vamos dar a eles ferramentas que são tão fáceis de usar que qualquer outro site que eu abrir acabará quebrando meu navegador. Uma implementação ingênua disso traria você diretamente para o território que causou a MS tantas dores de cabeça durante o desenvolvimento do IE7: autores adicionais jogaram rápido e solto com o modelo de threading, resultando em bugs ocultos que se tornaram evidentes quando os ciclos de vida dos objects foram alterados no thread primário . MAU. Se você está escrevendo add-ons ActiveX multi-threaded para o IE, eu acho que vem com o território; não significa que precisa ir além disso.

O multi-threading de JavaScript (com algumas limitações) está aqui. O Google implementou funcionários para o Gears e os funcionários estão sendo incluídos no HTML5. A maioria dos navegadores já adicionou suporte para esse recurso.

A segurança de thread de dados é garantida porque todos os dados comunicados de / para o trabalhador são serializados / copiados.

Para mais informações, leia:

http://www.whatwg.org/specs/web-workers/current-work/

http://ejohn.org/blog/web-workers/

Eu não sei a razão para essa decisão, mas sei que você pode simular alguns dos benefícios da programação multi-thread usando o setTimeout. Você pode dar a ilusão de vários processos fazendo coisas ao mesmo tempo, embora, na realidade, tudo aconteça em um único segmento.

Apenas faça sua function funcionar um pouco e depois chame algo como:

 setTimeout(function () { ... do the rest of the work... }, 0); 

E qualquer outra coisa que precise ser feita (como atualizações da interface do usuário, imagens animadas, etc) acontecerá quando eles tiverem uma chance.

O Multithread.js envolve os Web Workers e permite um multithreading fácil no JS. Funciona em todos os novos navegadores, incluindo o iOS Safari. 🙂

Você quer dizer por que o idioma não suporta multithreading ou por que os mecanismos JavaScript nos navegadores não oferecem suporte a multithreading?

A resposta para a primeira pergunta é que o JavaScript no navegador deve ser executado em uma sandbox e de forma independente da máquina / SO, para adicionar suporte a multithreads complicaria o idioma e ligaria a linguagem muito de perto ao sistema operacional.

Assim como matt b disse, a questão não é muito clara. Supondo que você esteja perguntando sobre o suporte a multithreading no idioma: porque ele não é necessário para 99,999% dos aplicativos em execução no navegador atualmente. Se você realmente precisar dele, existem soluções alternativas (como usar window.setTimeout).

Em geral, o multithreading é muito, muito, muito, muito, muito difícil (eu disse que é difícil?) Acertar, a menos que você coloque restrições extras (como usar apenas dados imutáveis).

A Intel tem feito uma pesquisa de código aberto sobre multithreading em Javascript, foi exibida recentemente na GDC 2012. Aqui está o link para o vídeo . O grupo de pesquisa usou o OpenCL, que se concentra principalmente nos chipsets Intel e no sistema operacional Windows. O projeto é codinome RiverTrail e o código está disponível no GitHub

Alguns links mais úteis:

Construindo uma rodovia de computação para aplicativos da Web

Atualmente, alguns navegadores suportam multithreading. Então, se você precisar, você pode usar bibliotecas específicas. Por exemplo, veja os próximos materiais:

Tanto quanto eu ouvi o Google Chrome terá javascript multithreaded, por isso é um problema de “implementações atuais”.

De acordo com este artigo , já é possível implementar o encadeamento JavaScript.

São as implementações que não suportam multi-threading. Atualmente, o Google Gears está fornecendo uma maneira de usar alguma forma de simultaneidade, executando processos externos, mas é sobre isso.

O novo navegador que o Google deve lançar hoje (Google Chrome) executa alguns códigos em paralelo, separando-o no processo.

A linguagem principal, é claro, pode ter o mesmo suporte que, digamos, Java, mas o suporte para algo como a concorrência de Erlang não está nem perto do horizonte.

Sem o suporte de idioma adequado para a synchronization de threads, não faz sentido que novas implementações sejam tentadas. Aplicativos JS complexos existentes (por exemplo, qualquer coisa usando ExtJS) provavelmente travariam inesperadamente, mas sem uma palavra synchronized chave synchronized ou algo semelhante, também seria muito difícil ou mesmo impossível escrever novos programas que se comportassem corretamente.

No entanto, você pode usar a function eval para trazer a simultaneidade PARA ALGUMA EXTENSÃO

 /* content of the threads to be run */ var threads = [ [ "document.write('Foo 
');", "document.write('Foo
');", "document.write('Foo
');", "document.write('Foo
');", "document.write('Foo
');", "document.write('Foo
');", "document.write('Foo
');", "document.write('Foo
');", "document.write('Foo
');", "document.write('Foo
');" ], [ "document.write('Bar
');", "document.write('Bar
');", "document.write('Bar
');", "document.write('Bar
');", "document.write('Bar
');", "document.write('Bar
');", "document.write('Bar
');", "document.write('Bar
');", "document.write('Bar
');" ] ]; window.onload = function() { var lines = 0, quantum = 3, max = 0; /* get the longer thread length */ for(var i=0; i

O multi-threading com javascript é claramente possível usando webworkers trazidos pelo HTML5.

A principal diferença entre webworkers e um ambiente multi-threading padrão é que os resources de memory não são compartilhados com o thread principal, uma referência a um object não é visível de um thread para outro. Os threads se comunicam trocando mensagens, portanto, é possível implementar um algoritmo de chamada de método simultâneo e de synchronization seguindo um padrão de design orientado a events.

Existem muitos frameworks que permitem estruturar a programação entre os threads, entre eles o OODK-JS, um framework OPS js que suporta programação simultânea https://github.com/GOMServices/oodk-js-oop-for-js