JavaScript multi-threading

Il multithreading non verrà eseguito in EcmaScript ma può essere esposto negli ambienti host.

Gli esempi classici sono WebWorkers che ti permettono di ruotare un lavoratore in background che lavora e abusa del <iframe> come metodo per generare nuovi processi.

Va notato che non è necessario il multi-threading in JavaScript (ci sono eccezioni, principalmente programmi relativi alla grafica). Non hai bisogno di più thread, hai già un loop di eventi per la tua GUI e il tuo rendering grafico (canvas) è accelerato dall'hardware (significa che la GPU renderà la tua grafica in parallelo per te).

Sebbene progetti come webcl siano piuttosto eccitanti.

No

Il multi-threading è una delle cose più difficili nel software per avere ragione. Ci sono troppi casi d'angolo che sono davvero difficili da capire quando il tuo codice non è deterministico. (Sto parlando di multi-threading con serrature ecc.). Inoltre, tutte le varie librerie JavaScript sono basate sul presupposto che non sia multi-thread.

Detto questo ci sono web worker che ti danno un framework basato sugli attori per fare operazioni di tipo multi-processing. È possibile creare lavoratori e passare i dati avanti e indietro tramite eventi.

Modifica L'altro motivo è che quando JavaScript è stato creato, è stato fatto così con l'ipotesi che sarebbe stato utilizzato per attività di piccole dimensioni, quindi non è stata creata alcuna concorrenza. Per riadattarla ora si romperebbe un sacco di codice. Aggiungendo web worker è stato possibile avere un sistema dove c'è concorrenza senza memoria condivisa, ma usando attori, un modello di concorrenza che si è dimostrato molto robusto in un certo numero di altri linguaggi come Erlang, Scala, Clojure ecc.

(SE non si può dire che non mi piace davvero la concorrenza basata sul blocco)

l'apertura di javascript per il multithreading creerà più problemi di quanti ne risolva:

l'architettura corrente è basata su eventi a thread singolo (esecuzione nel thread gui più spesso che no), in altre parole con ogni blocco di codice si può essere certi che nulla nell'ambiente cambierà dall'inizio alla fine eccetto cosa è cambiato nel codice.

non appena abiliti la preemption o l'esecuzione parallela questa funzione sarà sparita, questo significa che devi applicare i blocchi ai dati che vuoi modificare e avere l'intero hard debug delle condizioni di gara per evitare

è possibile avere un'esecuzione pseudo-parallela utilizzando i timeout, questo significa dividere le funzioni di grandi dimensioni o di lunga durata in blocchi atomici e usare setTimeout(function(){nextstep(args);},1); in modo che altre cose possano essere eseguite se necessario

Intel ha rilasciato qualche tempo fa River Trail , che consente la programmazione parallela in Javascript. Tuttavia, è un plugin solo per Firefox e non ho sentito parlare di una tabella di marcia che porti questa tecnologia nel W3C, molto meno ECMA.