Domanda

Si tratta di una decisione progettuale deliberata o di un problema con i browser attuali che verrà risolto nelle prossime versioni?

È stato utile?

Soluzione

JavaScript non supporta il multi-threading perché l'interprete JavaScript nel browser è un thread singolo (AFAIK).Anche Google Chrome non consentirà l'esecuzione simultanea di JavaScript di una singola pagina Web perché ciò causerebbe enormi problemi di concorrenza nelle pagine Web esistenti.Tutto ciò che Chrome fa è separare più componenti (diverse schede, plug-in, ecc.) in processi separati, ma non riesco a immaginare una singola pagina con più di un thread JavaScript.

È tuttavia possibile utilizzare, come suggerito, setTimeout per consentire una sorta di pianificazione e concorrenza “falsa”.Ciò fa sì che il browser riprenda il controllo del thread di rendering e avvii il codice JavaScript fornito setTimeout dopo il numero specificato di millisecondi.Ciò è molto utile se vuoi consentire l'aggiornamento della finestra (ciò che vedi) mentre esegui operazioni su di essa.Basta scorrere ad es.le coordinate e l'aggiornamento di un elemento di conseguenza ti consentiranno solo di vedere le posizioni iniziale e finale e nulla nel mezzo.

Utilizziamo una libreria di astrazione in JavaScript che ci consente di creare processi e thread gestiti tutti dallo stesso interprete JavaScript.Questo ci consente di eseguire azioni nel modo seguente:

  • Processo A, thread 1
  • Processo A, thread 2
  • Processo B, thread 1
  • Processo A, thread 3
  • Processo A, thread 4
  • Processo B, thread 2
  • Mettere in pausa il processo A
  • Processo B, thread 3
  • Processo B, discussione 4
  • Processo B, discussione 5
  • Avvia il processo A
  • Processo A, thread 5

Ciò consente una qualche forma di pianificazione e falso parallelismo, avvio e arresto di thread, eccetera, ma non sarà un vero multi-threading.Non penso che sarà mai implementato nel linguaggio stesso, dal momento che il vero multi-threading è utile solo se il browser può eseguire una singola pagina multi-thread (o anche più di un core), e le difficoltà sono molto maggiori rispetto alle possibilità extra.

Per il futuro di JavaScript, dai un'occhiata a questo:https://developer.mozilla.org/presentations/xtech2006/javascript/

Altri suggerimenti

Tradizionalmente, JS era destinato a porzioni di codice brevi e veloci.Se avevi calcoli importanti in corso, lo facevi su un server: l'idea di JS+HTML app che girasse nel tuo browser per lunghi periodi di tempo facendo cose non banali era assurdo.

Certo, ora ce l'abbiamo.Ma ci vorrà un po' prima che i browser si adeguino: la maggior parte di essi è stata progettata attorno a un modello a thread singolo e cambiarlo non è facile.Google Gears evita molti potenziali problemi richiedendo che l'esecuzione in background sia isolata: nessuna modifica del DOM (poiché non è thread-safe), nessun accesso agli oggetti creati dal thread principale (idem).Sebbene restrittivo, questo sarà probabilmente il design più pratico per il prossimo futuro, sia perché semplifica la progettazione del browser, sia perché riduce il rischio di consentire a programmatori JS inesperti di scherzare con i thread...

@marcio:

Perché questo è un motivo per non implementare il multi-threading in Javascript?I programmatori possono fare quello che vogliono con gli strumenti a loro disposizione.

Allora non diamo loro strumenti così facili da usare abuso che ogni altro sito web che apro finisce per mandare in crash il mio browser.Un'implementazione ingenua di questo ti porterebbe direttamente nel territorio che ha causato così tanti grattacapi a MS durante lo sviluppo di IE7:gli autori dei componenti aggiuntivi hanno giocato in modo rapido e rilassato con il modello di threading, risultando in bug nascosti che diventavano evidenti quando i cicli di vita degli oggetti cambiavano nel thread principale.CATTIVO.Se stai scrivendo componenti aggiuntivi ActiveX multi-thread per IE, immagino che venga fornito con il territorio;non significa che bisogna andare oltre.

Il multi-threading JavaScript (con alcune limitazioni) è qui.Google ha implementato i lavoratori per Gears e i lavoratori vengono inclusi in HTML5.La maggior parte dei browser ha già aggiunto il supporto per questa funzionalità.

La sicurezza dei thread dei dati è garantita poiché tutti i dati comunicati al/dal lavoratore vengono serializzati/copiati.

Per maggiori informazioni leggi:

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

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

Non conosco la logica di questa decisione, ma so che puoi simulare alcuni dei vantaggi della programmazione multi-thread utilizzando setTimeout.Puoi dare l'illusione che più processi facciano cose contemporaneamente, anche se in realtà tutto avviene in un unico thread.

Basta che la tua funzione faccia un po' di lavoro e poi chiami qualcosa come:

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

E qualsiasi altra cosa da fare (come aggiornamenti dell'interfaccia utente, immagini animate, ecc.) accadrà quando ne avranno la possibilità.

Multithread.js avvolge i Web Worker e consente un facile multithreading in JS.Funziona su tutti i nuovi browser, incluso iOS Safari.:)

Intendi perché il linguaggio non supporta il multithreading o perché i motori JavaScript nei browser non supportano il multithreading?

La risposta alla prima domanda è che JavaScript nel browser è pensato per essere eseguito in una sandbox e in modo indipendente dalla macchina/dal sistema operativo, aggiungere il supporto multithreading complicherebbe il linguaggio e legherebbe troppo strettamente il linguaggio al sistema operativo.

Proprio come ha detto Matt B, la domanda non è molto chiara.Supponendo che tu stia chiedendo del supporto multithreading nella lingua:perché attualmente non è necessario per il 99,999% delle applicazioni in esecuzione nel browser.Se ne hai davvero bisogno, ci sono soluzioni alternative (come usare window.setTimeout).

In generale il multithreading è molto, molto, molto, molto, molto, molto difficile (ho detto che è difficile?) da eseguire correttamente, a meno che non si inseriscano ulteriori restrizioni (come l'utilizzo solo di dati immutabili).

Intel ha condotto alcune ricerche open source sul multithreading in Javascript, presentate recentemente al GDC 2012.Ecco il collegamento per il video.Il gruppo di ricerca ha utilizzato OpenCL che si concentra principalmente sui set di chip Intel e sul sistema operativo Windows.Il progetto ha il nome in codice RiverTrail e il codice è disponibile su GitHub

Alcuni link più utili:

Costruire un'autostrada informatica per applicazioni Web

Attualmente alcuni browser supportano il multithreading.Quindi, se ne hai bisogno, potresti utilizzare librerie specifiche.Ad esempio, visualizza i materiali successivi:

Supporta Node.js 10.5+ thread di lavoro come funzionalità sperimentale (puoi usarla con --lavoratore-sperimentale flag abilitato): https://nodejs.org/api/worker_threads.html

Quindi, la regola è:

  • se hai bisogno di farlo Operazioni legate all'I/O, quindi utilizza il meccanismo interno (noto anche come callback/promise/async-await)
  • se hai bisogno di farlo Operazioni legate alla CPU, quindi utilizzare i thread di lavoro.

I thread di lavoro sono pensati per essere thread di lunga durata, il che significa che si genera un thread in background e quindi si comunica con esso tramite lo scambio di messaggi.

Altrimenti, se devi eseguire un carico pesante della CPU con una funzione anonima, puoi farlo https://github.com/wilk/microjob, una piccola libreria costruita attorno ai thread di lavoro.

Sono le implementazioni che non supportano il multi-threading.Attualmente Google Gears fornisce un modo per utilizzare una qualche forma di concorrenza eseguendo processi esterni, ma questo è tutto.

Il nuovo browser che Google dovrebbe rilasciare oggi (Google Chrome) esegue parte del codice in parallelo separandolo nel processo.

Il linguaggio principale, ovviamente, può avere lo stesso supporto, ad esempio, di Java, ma il supporto per qualcosa come la concorrenza di Erlang non è affatto vicino all'orizzonte.

Per quanto ho sentito, Google Chrome avrà Javascript multithread, quindi è un problema di "implementazioni attuali".

Secondo Questo articolo è già possibile implementare il threading JavaScript.

Senza un adeguato supporto linguistico per la sincronizzazione dei thread, non ha nemmeno senso provare nuove implementazioni.App JS complesse esistenti (ad es.qualsiasi cosa che utilizzi ExtJS) molto probabilmente si bloccherebbe inaspettatamente, ma senza a synchronized parola chiave o qualcosa di simile, sarebbe anche molto difficile o addirittura impossibile scrivere nuovi programmi che si comportino correttamente.

Tuttavia è possibile utilizzare la funzione eval per portare la concorrenza IN UNA CERTA MISURA

/* content of the threads to be run */
var threads = [
        [
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');"
        ],
        [
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');"
        ]
    ];

window.onload = function() {
    var lines = 0, quantum = 3, max = 0;

    /* get the longer thread length */
    for(var i=0; i<threads.length; i++) {
        if(max < threads[i].length) {
            max = threads[i].length;
        }
    }

    /* execute them */
    while(lines < max) {
        for(var i=0; i<threads.length; i++) {
            for(var j = lines; j < threads[i].length && j < (lines + quantum); j++) {
                eval(threads[i][j]);
            }
        }
        lines += quantum;
    }
}

puoi usare jetworker, wrapper su webworkerhttps://github.com/uxitten/jetworker

Il multithreading con Javascript è chiaramente possibile utilizzando i webworker portati da HTML5.

La differenza principale tra i webworker e un ambiente multi-threading standard è che le risorse di memoria non sono condivise con il thread principale, un riferimento a un oggetto non è visibile da un thread all'altro.I thread comunicano scambiandosi messaggi, è quindi possibile implementare un algoritmo di sincronizzazione e chiamata di metodi concorrenti seguendo un design pattern event-driven.

Esistono molti framework che consentono di strutturare la programmazione tra thread, tra cui OODK-JS, un framework OOP js che supporta la programmazione simultaneahttps://github.com/GOMServices/oodk-js-oop-for-js

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top