Perché i browser serrano timeout e intervalli?

Question

Perché i browser serrano timeout e intervalli?

#1 da (2 voti)

3

Ho lavorato su alcune astrazioni di setTimeout e setInterval per elaborare grandi insiemi di dati senza bloccare il ciclo degli eventi nel browser.

Su questo, ho scoperto che i browser "bloccano" il numero di millisecondi specificato per un timeout o un intervallo.

Ad esempio, se scrivi setTimeout('do something', 0) , il browser farà effettivamente setTimeout('do something', 4) . In altre parole, il browser imporrà da 2 a 10 millisecondi, a seconda del browser e della versione in cui viene eseguito il codice.

Questo può avere un grande impatto sulla quantità di tempo per un callback / promessa di aspettare. Ci sono modi per aggirare questo (per timeout, comunque), come usare postMessage o MessageChannel (soluzioni povere, secondo me); possono fornire lo stesso effetto di un timeout mentre hanno effettivamente 0 tempo di attesa.

Perché i browser bloccano timeout e intervalli in questo modo? Non riesco a trovare alcun ragionamento per questo, ufficiale o altro. La mia unica ipotesi è che in qualche modo consente di aggiungere altri compiti allo stack delle chiamate, ma questo non sembra essere un problema con postMessage per quanto posso dire, quindi oltre a ciò non posso pensare a nessun motivo per cui questo aiuta chiunque.

javascript async browser event-programming time

posta Ravenstine 08.01.2015 - 18:27

fonte

1 risposta

Leggi altre domande sui tag javascript async browser event-programming time

Cercando di elaborare il POST parziale dei dati in REST quando alcuni dati hanno esito positivo? Test di integrazione della logica SQL

score 2 · Accepted Answer

Non posso dire molto sui motivi per cui, ma sulla base di una documentazione "ufficiale" che può aiutare nelle tue indagini sull'argomento.

Soprattutto le specifiche HTML 5 indicate di seguito potrebbero contenere suggerimenti interessanti per continuare l'indagine.

Il documentazione MDN su setTimeout dice:

Minimum/ maximum delay and timeout nesting

Historically browsers implement setTimeout() "clamping": successive setTimeout() calls with delay smaller than the "minimum delay" limit are forced to use at least the minimum delay. The minimum delay, DOM_MIN_TIMEOUT_VALUE, is 4 ms (stored in a preference in Firefox: dom.min_timeout_value), with a DOM_CLAMP_TIMEOUT_NESTING_LEVEL of 5ms.

In fact, 4ms is specified by the HTML5 spec and is consistent across browsers released in 2010 and onward. Prior to (Firefox 5.0 / Thunderbird 5.0 / SeaMonkey 2.2), the minimum timeout value for nested timeouts was 10 ms.

In addition to "clamping", the timeout can also fire later when the page (or the OS/browser itself) is busy with other tasks.

To implement a 0 ms timeout in a modern browser, you can use window.postMessage() as described here.

Browsers including Internet Explorer, Chrome, Safari, and Firefox store the delay as a 32-bit signed Integer internally. This causes an Integer overflow when using delays larger than 2147483647, resulting in the timeout being executed immediately.