setTimeout () funziona davvero in parallelo?

Question

setTimeout () funziona davvero in parallelo?

#1 da (6 voti)
#2 da (3 voti)
#3 da (3 voti)

1

Considera il seguente codice JavaScript:

function foo(ary) {
  // some long operation on ary
}
function bar(ary) {
  // some long operation on ary
}
function baz(ary) {
  // some long operation on ary
}

function main(ary) {
  setTimeout(foo, 0, ary);
  setTimeout(bar, 0, ary);
  setTimeout(baz, 0, ary);
}

main([some large array]);

Da MDN setTimeout () :

Code executed by setTimeout() is run in a separate execution context to the function from which it was called.

Ma questo significa che viene eseguito in parallelo a qualsiasi altro codice attualmente in lavorazione?

Considerando l'esempio che ho postato sopra, supponendo che un array molto grande venga elaborato da 3 funzioni, ognuna eseguendo un'operazione molto lunga ma indipendente l'una dall'altra, le 3 funzioni saranno eseguite in parallelo?

C'è un modo per mostrare l'esecuzione di (più) setTimeouts , magari usando Chrome Dev Tools?

javascript

posta Harsh Gupta 05.04.2016 - 10:21

fonte

3 risposte

3

But does this mean it executes in parallel to any other code that is currently in process?

No, non significa quello. Verrà eseguito più tardi, quando sarà trascorso il tempo specificato.

Javascript fondamentalmente non supporta il multithreading perché non ci sono funzionalità linguistiche che impediscano il danneggiamento dei dati dall'accesso simultaneo né che i thread isolati comunichino tramite la messaggistica.

Un motore JavaScript elabora semplicemente una coda di eventi in sequenza su un singolo thread. Quando la coda degli eventi è vuota, quel thread rimane inattivo. In un browser, gli eventi vengono aggiunti alla coda in base all'input dell'utente, al caricamento della pagina e così via. Negli eventi node.js possono anche essere richieste HTTP o eventi hardware. E setTimeout() aggiunge semplicemente un altro tipo di evento con la condizione aggiuntiva che dovrebbe essere aggiunto alla coda solo dopo che è trascorso un certo tempo.

Il "contesto di esecuzione separato" menzionato nella documentazione significa solo che il riferimento this sarà diverso rispetto alla funzione in cui è chiamato setTimeout() .

risposta data 05.04.2016 - 10:39

fonte

3

Per "contesto di esecuzione separato", il documento significa in particolare che this sarà diverso in ogni probabilità.

Nel browser, il codice JavaScript di una pagina viene sempre eseguito in un singolo thread. Solo JavaScript eseguito in un lavoratore o in una pagina separata può essere eseguito in parallelo.

Una ragione di ciò è che JavaScript ha accesso diretto al DOM e ottenere risultati sicuri in termini di sicurezza. Il ragionamento è abbastanza simile per nodejs.

risposta data 05.04.2016 - 10:39

fonte

Leggi altre domande sui tag javascript

Cosa significa costruire dalla sorgente? Come si chiama questo modello?

score 6 · Accepted Answer

No, non è così. "Contesto di esecuzione" non significa "thread" e fino a poco tempo fa Javascript non supportava nulla di simile ai thread. Ciò che accade in realtà è che un evento viene inserito nella coda eventi impostata per essere eseguita nel numero di millisecondi specificato dal secondo argomento su SetTimeout / SetInterval. La conseguenza di ciò è che se si richiede un ritardo di 1000 ms, allora 1000 ms è il ritardo MINIMO che si otterrà. Se il motore di esecuzione è impegnato a fare qualcos'altro quando il ritardo di 1000 ms è finito, dovrà attendere fino a quando non avrà finito con quello che sta facendo.

"Contesto di esecuzione" si riferisce a quali regole di scope variabili verranno applicate al callback setTimeout, il che significa che la variabile this potrebbe non puntare a ciò che pensi che sarà, ecc.

link