framework - node.js server-side javascript que es
¿Cómo funciona setTimeout en Node.JS? (5)
La única manera de garantizar que el código se ejecute es colocar su lógica setTimeout en un proceso diferente.
Use el módulo de proceso hijo para generar un nuevo programa node.js que haga su lógica y pase datos a ese proceso a través de algún tipo de transmisión (tal vez tcp).
De esta forma, incluso si se ejecuta un código de bloqueo largo en su proceso principal, su proceso hijo ya se ha iniciado y ha colocado un setTimeout en un nuevo proceso y un nuevo hilo, y se ejecutará cuando lo espere.
Otras complicaciones se encuentran en un nivel de hardware en el que hay más hilos que ejecutan los procesos y, por lo tanto, el cambio de contexto provocará retrasos (muy pequeños) en el tiempo previsto. Esto debería ser insignificante y, si es importante, debe considerar seriamente lo que intenta hacer, por qué necesita tal precisión y qué tipo de hardware alternativo en tiempo real está disponible para hacer el trabajo.
En general, utilizar procesos secundarios y ejecutar múltiples aplicaciones de nodo como procesos separados junto con un equilibrador de carga o almacenamiento de datos compartidos (como redis) es importante para escalar su código.
Supongo que una vez que se ejecuta, está en la cola, pero en la cola hay alguna garantía de que invocará exactamente después de X milisegundos. ¿O otras tareas pesadas en la cola lo retrasarán?
La idea de no bloqueo es que las iteraciones de bucle sean rápidas. Por lo tanto, para iterar para cada tick debería tomarse un tiempo suficientemente corto para que setTimeout sea preciso con una precisión razonable (aproximadamente 10 ms menos).
En teoría, tienes razón. Si escribo una aplicación y bloqueo el tic, se retrasará setTimeouts. Entonces, para responder a su pregunta, ¿quién puede asegurar que setTimeouts se ejecute a tiempo? Usted, al escribir un código que no sea de bloqueo, puede controlar el grado de precisión hasta casi cualquier grado razonable de precisión.
Siempre que javascript sea de "un único subproceso" en términos de ejecución de código (excluyendo web-workers y similares), eso siempre ocurrirá. La naturaleza de un único subproceso es una gran simplificación en la mayoría de los casos, pero requiere que el modismo no bloqueante sea exitoso.
Pruebe este código en su navegador o en su nodo, y verá que no hay garantía de precisión, por el contrario, el setTimeout será muy tarde:
var start = Date.now();
// expecting something close to 500
setTimeout(function(){ console.log(Date.now() - start); }, 500);
// fiddle with the number of iterations depending on how quick your machine is
for(var i=0; i<5000000; ++i){}
A menos que el intérprete optimice el bucle (lo que no ocurre en Chrome), obtendrá algo entre miles. Quita el lazo y verás que es 500 en la nariz ...
La semántica de setTimeout es más o menos la misma que en un navegador web: el tiempo de espera arg es un número mínimo de ms para esperar antes de la ejecución, no una garantía. Además, al pasar 0, un número no numérico o un número negativo, hará que espere un número mínimo de ms. En el nodo, esto es 1 ms, pero en los navegadores puede ser de hasta 50 ms.
La razón de esto es que no hay preferencia de JavaScript por JavaScript. Considera este ejemplo:
setTimeout(function () {
console.log(''boo'')
}, 100)
var end = Date.now() + 5000
while (Date.now() < end) ;
console.log(''imma let you finish but blocking the event loop is the best bug of all TIME'')
El flujo aquí es:
- programar el tiempo de espera para 100 ms.
- busywait por 5000ms.
- regresar al ciclo de eventos. verifica los temporizadores pendientes y ejecuta.
Si este no fuera el caso, entonces podría tener un bit de JavaScript que "interrumpa" a otro. Tendríamos que configurar mutexes y semaforos y cosas así, para evitar que un código como este sea extremadamente difícil de razonar:
var a = 100;
setTimeout(function () {
a = 0;
}, 0);
var b = a; // 100 or 0?
El hilo único de la ejecución de JavaScript de Node hace que sea mucho más simple trabajar con él que la mayoría de los otros estilos de concurrencia. Por supuesto, la desventaja es que es posible que una parte del programa con mal comportamiento bloquee todo con un ciclo infinito.
¿Es este un mejor demonio de batalla que la complejidad de la apropiación? Eso depende.
setTimeout(callback,t) se usa para ejecutar la devolución de llamada después de al menos t milisegundos . La demora real depende de muchos factores externos, como la granularidad del temporizador del sistema operativo y la carga del sistema.
Por lo tanto, existe la posibilidad de que se llame ligeramente después de la hora establecida, pero nunca se llamará antes.
Un temporizador no puede abarcar más de 24.8 días.
setTimeout es un tipo de Thread , tiene una operación por un tiempo determinado y se ejecuta.
setTimeout(function,time_in_mills);
aquí el primer argumento debe ser un tipo de función, como un ejemplo si desea imprimir su nombre después de 3 segundos, su código debería ser algo similar a continuación.
setTimeout(function(){console.log(''your name'')},3000);
Lo más importante que hay que recordar es que, lo que quieras hacer utilizando el método setTimeout , hazlo dentro de una función. Si quieres llamar a algún otro método parchando algunos parámetros, tu código debe verse como se muestra a continuación.
setTimeout(function(){yourOtherMethod(parameter);},3000);
happy nodejs codificación :)