2010-07-09 15 views
5

perche il seguente codice e la spiegazione di questa esercitazione Mozilla "Using web workers":Condizioni di gara con i web worker quando si imposta un gestore di messaggi?

var myWorker = new Worker('my_worker.js'); 
myWorker.onmessage = function(event) { 
    print("Called back by the worker!\n"); 
}; 

linea 1 in questo esempio crea e inizia in esecuzione il thread di lavoro. Riga 2 imposta il gestore onmessage per l'operatore su una funzione che è chiamata quando l'operatore chiama la propria funzione postMessage().

Il filo viene avviato nel momento in cui il lavoratore costruttore viene chiamato. Mi chiedo se potrebbe esserci una condizione di competizione durante l'impostazione del gestore onmessage. Ad esempio se il web worker invia un messaggio prima di onmessage è impostato.

Qualcuno ne sa di più?

Aggiornamento:

Andrey ha sottolineato che il lavoratore web dovrebbe iniziare il suo lavoro, quando riceve un messaggio, come nell'esempio Fibonacci nel tutorial di Mozilla. Ma questo non crea una nuova condizione di razza quando si imposta il gestore onmessage nel web worker?

Ad esempio:

Lo script principale:

var myWorker = new Worker('worker.js'); 
myWorker.onmessage = function(evt) {..}; 
myWorker.postMessage('start'); 

Lo script operaio web ('') worker.js

var result = []; 
onmessage = function(evt) {..}; 

e quindi considerare il seguente percorso di esecuzione:

main thread         web worker 
var worker = new Worker("worker.js"); 
              var result = []; 
myWorker.onmessage = .. 
myWorker.postMessage('start'); 
              onmessage = .. 

Th e "var result = []" la riga può essere omessa, sarà comunque lo stesso effetto.

E questo è un percorso di esecuzione valido, l'ho provato impostando un timeout nel web worker! Al momento non riesco a vedere, come usare i web worker senza incorrere in condizioni di gara ?!

risposta

3

La risposta è che sia lo script principale e l'operaio web hanno una coda MessagePort che raccoglie i messaggi prima che lo script iniziale lavoratore ritorna.

Per i dettagli, si veda questo thread sul aiuto mailing list WHATWG: http://lists.whatwg.org/pipermail/help-whatwg.org/2010-August/000606.html

+0

Il collegamento alla mailing list è ora rotto. Qualche idea su dove leggere il thread o, in alternativa, c'erano dei trucchi? – HRJ

+0

@HRJ Spiacente, non riesco a trovare una versione archiviata del thread. Ma non ci sono trucchi, una coda di messaggi fa in modo che non ti devi preoccupare delle condizioni di gara. – tsauerwein

2

Sì, è possibile causare condizioni di gara qui. La responsabilità spetta allo sviluppatore di Worker. Dovrebbe iniziare a pubblicare i messaggi solo dopo aver ricevuto il messaggio tramite postMessage(). Nel costruttore deve solo eseguire l'inizializzazione, ma non l'elaborazione effettiva. Nella sezione Esempi della tua pagina c'è un bel campione sui numeri di fibonachi. Guarda la sua struttura, il vero lavoro inizia quando il messaggio viene ricevuto. Segui quel modello.

+2

Che cosa succede se il thread principale invia il suo messaggio di avvio, prima che il lavoratore web ha impostato il suo gestore onMessage? È possibile? – tsauerwein