Multi Threading JavaScript

10

Hoje em dia, o JavaScript é o principal player em todas as tecnologias de desenvolvimento da web, no lado do cliente, para melhorar a interface do usuário, a lógica do lado do cliente, em alguns servidores da web, como a lógica do lado do servidor também

Acrescente a isso o fato de as pessoas (pelo menos algumas delas) começarem a se mover no desenvolvimento de jogos na web, de flash para javascript e HTML5

Não é hora de oferecer suporte a multi threading! existem navegadores que permitem que o JavaScript seja multiencadeado ou existe em algum padrão, HTML5 ou versões futuras ?!

— Todos
fonte

11

As pessoas não fazem coisas que não são necessárias. As pessoas que contribuíram no design do Javascript também são as que estão relacionadas com o desenvolvimento de servidores e navegadores da Web, para que eles soubessem disso. É tudo sobre utilidade.

— Dipan Mehta

9

O multiencadeamento não será realizado no EcmaScript, mas poderá ser exposto em ambientes host.

Os exemplos clássicos são WebWorkers, que permitem que você crie um trabalhador em segundo plano para realizar trabalhos e abusar deles<iframe> como uma maneira de gerar novos processos.

Deve-se notar que a multiencadeamento em JavaScript não é necessária (há exceções, principalmente programas relacionados a gráficos). Você não precisa de vários threads, já possui um loop de eventos para sua GUI e a renderização gráfica (canvas) é acelerada por hardware (ou seja, a GPU renderiza seus gráficos em paralelo para você).

Embora projetos como o webcl sejam bastante empolgantes.

— Raynos
fonte

2

Você pode expandir o fato de que "não é necessário"? Encontrei recentemente uma instância em que o caso natural da programação de desktops era gerar um thread para lidar com a tarefa, mas isso obviamente não era uma opção fácil ou padrão. Eu trabalhei em torno desse caso, mas gerar um fio parecia ser a solução mais elegante.

— Rig

@rig qual foi o caso que você estava tentando lidar?

— Zachary K

@Rig dá um exemplo concreto. computacionalmente processamento caro é raro no lado do cliente JavaScript

— Raynos

@ Raynos, por favor, explique mais sobre como isso não é necessário, só estou pensando que não no desenvolvimento de jogos, por exemplo, se houver computação pesada em gráficos e em física e taxa de quadros lógicos e físicos serão facilmente afetados se não houver multithreading, acho

— Ali

@ Ali eu fugi e disse que há exceções. No entanto a maior parte desse pesado computação deve ser dada para a GPU através do hardware gráficos acelerados API

— Raynos

4

NÃO

O multi threading é uma das coisas mais difíceis do software para acertar. Existem muitos casos extremos que são realmente difíceis de resolver quando o seu código não é determinístico. (Eu estou falando sobre multi threading com bloqueios etc). Além disso, todas as várias bibliotecas JavaScript são criadas com base no pressuposto de que não são multiencadeadas.

Dito isto, existem trabalhadores da Web que fornecem uma estrutura baseada em ator para realizar operações de tipo de processamento múltiplo. Você pode criar trabalhadores e repassar dados através de eventos.

EDIT: O outro motivo é que, quando o JavaScript foi criado, era feito com a suposição de que ele seria usado para pequenas tarefas; portanto, nenhuma simultaneidade foi incorporada. Para a atualização, agora ele quebraria muito código. Ao adicionar trabalhadores da Web, foi possível ter um sistema onde houvesse simultaneidade sem memória compartilhada, mas usando atores, um modelo de simultaneidade que se mostrou muito robusto em vários outros idiomas como Erlang, Scala, Clojure etc.

(SE você não pode dizer que eu realmente não gosto de simultaneidade baseada em bloqueio)

— Zachary K
fonte

11

Multi threading is one of the hardest things in software to get right.- Eu apenas surpreendi com isso! O navegador que você está usando, o SO da área de trabalho, o servidor da web que serve esta página - praticamente todos os aplicativos que você usa todos os dias são multithread. Tem certeza de que quer dizer isso? Ainda para diminuir seu voto, mas eu o farei se você disser #multithreading is not done because it is hard

— Dipan Mehta

3

O multi-threading do @DipanMehta é uma das coisas mais difíceis do software para acertar. A razão todas aquelas aplicações usá-lo é porque eles são escritos por pessoas realmente talentosas

— Raynos

@ Raynos - meu Deus! Então você está me chamando de talentoso! Eu uso todos os dias ... acho que quando você está programando C ou qualquer aplicativo de larga escala, é bastante comum. O ponto é que, independentemente do uso e dos requisitos, o consórcio W3C realmente não o poupou para Javascript porque era muito difícil !

— Dipan Mehta

2

Você subestima severamente o quão difícil é escrever programas paralelos corretos e eficientes. Mas multi threading não é em JavaScript porque a sua complexidade desnecessária (a coisa foi escrito em 3 semanas)

— Raynos

2

@DipanMehta obter uma simultaneidade baseada em bloqueio e corrigir todos os casos de canto é um problema difícil. Por exemplo, uma implementação de algo tão simples quanto uma fila com bloqueios que possa ser comprovada correta em todos os casos teria sido um resultado publicável até alguns anos atrás. Mas, mais importante, tentar adaptar isso a um idioma que não o tenha, está pedindo problemas.

— Zachary K

3

abrir o javascript para multithreading criará mais problemas do que resolve:

a arquitetura atual é baseada em eventos de thread único (sendo executada no thread da GUI com mais frequência) em outras palavras, com cada bloco de código, você pode ter certeza de que nada no ambiente será alterado do início ao fim, exceto o que foi alterado no código

assim que você permitir a preempção ou a execução paralela, esse recurso será desativado, isso significa que você precisa aplicar bloqueios aos dados que deseja alterar, além de ter condições de corrida difíceis de depurar para evitar

é possível ter execução pseudo-paralela usando timeouts, isso significa dividir funções de execução grandes ou longas em partes atômicas e usar setTimeout(function(){nextstep(args);},1);para que outras coisas possam ser executadas, se necessário

— catraca arrepiante
fonte

0

A Intel lançou o River Trail há algum tempo, o que permite a programação paralela em Javascript. No entanto, é um plug-in somente do Firefox e não ouvi falar de um roteiro que traga essa tecnologia para o W3C, muito menos para o ECMA.

— Demian Brecht
fonte