2012-07-06 2 views

risposta

15

Il problema con i lavoratori del Web è che non si adattano perfettamente al modello GWT/Java standard, a mio avviso si adattano a malapena al modello JS standard.

Gli operatori Web lavorano passando i dati avanti e indietro tra le macchine virtuali JavaScript essenzialmente diverse. Questi dati devono essere sotto forma di stringa e ogni lavoratore deve caricare separatamente il proprio JS. Ciò significa che nessuna variabile dichiarata in un lavoratore (o nella pagina principale) è accessibile da un altro, a meno che non sia passata come parte dei dati della stringa, spostata avanti e indietro tra i lavoratori.

Quindi, come funziona quando si considera GWT/Java? Dal punto di vista Java, questo non è equivalente a più thread, ma più JVM! I diversi processi possono comunicare solo passando le stringhe (o, più importante, non gli oggetti Java) avanti e indietro, e non possono condividere altri stati. Anche le variabili statiche potrebbero essere diverse tra le due macchine virtuali.

Dal link che hai postato, controlla la fonte di JsWorker - è possibile creare un'istanza di questa via JsWindow.newWorker con l'url dello script JS per cominciare, e JsWorker supporta i metodi per ascoltare le risposte, e di inviarlo messaggi per dargli lavoro da fare.

Questo script potrebbe essere un oggetto compilato GWT, ma sarebbe un modulo separato e un punto di accesso diverso dall'app originale, in modo che abbia solo il codice che può essere ragionevolmente eseguito e non tenta di iniziare a disegnare sulla pagina quando carica. Probabilmente avrebbe bisogno di usare un linker che caricasse solo il JS e non assumerebbe un iframe sulla "pagina".

Il progetto GWT-NS contiene già alcuni esempi di web worker, creati utilizzando il proprio linker per creare file js da caricare nel worker e alcuni altri pezzi di convenienza.

+0

Risposta perfetta. Grazie! – JAre