JavaScript multi threading

10

Bene, in questi giorni JavaScript è il principale attore in tutte le tecnologie di sviluppo web, sul lato client per migliorare l'interfaccia utente, la logica lato client, su alcuni server Web come logica lato server

Aggiungete a ciò il fatto che le persone (almeno alcune) hanno iniziato a muoversi nello sviluppo di giochi Web da flash a javascript e HTML5

Non è ora che supporti il multi threading! ci sono browser che permettono a JavaScript di essere multi-thread o è presente in qualche standard, HTML5 o versioni future ?!

— Ali
fonte

1

Le persone non fanno cose che non sono necessarie. Le persone che hanno contribuito alla progettazione di Javascript, sono anche quelle relative ai server Web e ai browser in fase di sviluppo, in modo da conoscerlo. Si tratta di utilità.

— Dipan Mehta,

9

Il multi threading non verrà eseguito in EcmaScript ma può essere esposto in ambienti host.

Gli esempi classici sono WebWorker che ti consentono di creare un lavoratore in background per lavorare e abusare di <iframe>un modo per generare nuovi processi.

Va notato che il multi threading in JavaScript non è necessario (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 (il che significa che la GPU rende la tua grafica in parallelo per te).

Sebbene progetti come il webcl siano piuttosto eccitanti.

— Raynos
fonte

2

Puoi espandere il fatto che "non è necessario"? Mi sono imbattuto recentemente in un'istanza in cui il caso naturale nella programmazione desktop sarebbe quello di generare un thread per gestire l'attività, ma ovviamente non era un'opzione facile o standard. Ho lavorato attorno a quel caso, ma generare un filo sembrava essere la soluzione più elegante.

— Rig

@rig qual è stato il caso che stavi cercando di gestire?

— Zachary K

@Rig fai un esempio concreto. l'elaborazione computazionalmente costosa è rara nel JavaScript lato client

— Raynos

@Raynos, per favore, spiegate di più su come non è necessario, sto solo pensando di non essere sicuro che nello sviluppo del gioco, ad esempio, se ci sono pesanti calcoli sulla grafica e sulla fisica e il frame rate della logica sarà facilmente influenzato se non c'è multithreading, penso

— Ali

@Ali sono uscito e ho detto che ci sono eccezioni. Tuttavia, gran parte di quel pesante calcolo dovrebbe essere dato alla GPU tramite l'API grafica con accelerazione hardware

— Raynos

4

NO

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

Detto questo, ci sono web worker che ti danno un framework basato sull'attore per eseguire operazioni multi-elaborazione. È possibile creare lavoratori e passare i dati avanti e indietro tramite eventi.

EDIT: L'altro motivo è che quando è stato creato JavaScript, è stato fatto con il presupposto che sarebbe stato utilizzato per piccole attività, quindi non è stata integrata alcuna concorrenza. Per il retrofit ora si romperebbe molto codice. Aggiungendo i web worker è stato possibile avere un sistema in cui c'è concorrenza senza memoria condivisa, ma usando gli attori, un modello di concorrenza che si è dimostrato molto robusto in un numero di altre lingue come Erlang, Scala, Clojure eccetera.

(SE non puoi dire che non mi piace davvero la concorrenza basata sul blocco)

— Zachary K
fonte

1

Multi threading is one of the hardest things in software to get right.- Sono rimasto sorpreso da questo! Il browser che stai utilizzando, il sistema operativo del tuo desktop, il server web che serve questa pagina - praticamente ogni applicazione che usi tutti i giorni è multithread. SEI SICURO DI SIGNIFICARLO? Eppure per sottovalutarti, ma lo dirò se dicimultithreading is not done because it is hard

— Dipan Mehta

3

Il multithreading @DipanMehta è una delle cose più difficili da realizzare nel software. Il motivo per cui tutte queste applicazioni lo usano è perché sono scritti da persone di grande talento

— Raynos

@Raynos - mio Dio! Quindi mi stai chiamando talento! Lo uso tutti i giorni ... penso che quando si sta programmando C o qualsiasi applicazione su larga scala, è abbastanza comune. Il punto è che, indipendentemente dall'uso e dai requisiti, il consorzio W3C non lo ha risparmiato per Javascript perché era troppo difficile !

— Dipan Mehta,

2

Comprendi severamente quanto sia difficile scrivere programmi paralleli corretti ed efficienti. Ma il multi threading non è in JavaScript a causa della sua complessità non necessaria (la cosa è stata scritta in 3 settimane)

— Raynos

2

@DipanMehta ottenere una concorrenza basata su lock fatta bene e inchiodare tutti i casi d'angolo è un problema difficile. Ad esempio, l'implementazione di qualcosa di semplice come una coda con blocchi che può essere dimostrata corretta in tutti i casi sarebbe stato un risultato pubblicabile fino a pochi anni fa. Ma, cosa ancora più importante, cercare di adattarlo a una lingua che non ha avuto sta chiedendo problemi.

— Zachary K

3

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

l'architettura attuale è basata su eventi a thread singolo (in esecuzione nel thread gui il più delle volte) in altre parole con ogni blocco di codice si può essere certi che nulla nell'ambiente cambierà dall'inizio alla fine tranne ciò che è cambiato nel codice.

non appena si consente la preemption o l'esecuzione parallela questa funzione scompare, ciò significa che è necessario applicare i blocchi ai dati che si desidera mutare e avere le condizioni di gara complesse per il debug da evitare

è possibile avere un'esecuzione pseudo-parallela usando i timeout, questo significa dividere funzioni grandi o lunghe in blocchi atomici e usare setTimeout(function(){nextstep(args);},1); così altre cose possono essere eseguite se necessario

— maniaco del cricchetto
fonte

0

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

— Demian Brecht
fonte