La comprensión de principiante de Node es que si reescribo código síncrono o en línea para utilizar funciones/devoluciones de llamada, puedo asegurarme de que mi código no sea de bloqueo. Tengo curiosidad de cómo funciona esto en términos de la pila de eventos. El ejemplo simple de aquí: Don't understand the callback - Stackoverflow es que esto bloqueará:¿Por qué una función y una devolución de llamada no bloquean en Node.JS?
var post = db.query("select * from posts where id = 1");
doSomethingWithPost(post)
doSomethingElse();
Si bien esta costumbre:
callback = function(post){
doSomethingWithPost(post)
}
db.query("select * from posts where id = 1",callback);
doSomethingElse();
Ok, entiendo que debemos utilizar devoluciones de llamada. Pero en términos de la pila de eventos, ¿por qué funciona esto? Javascript tiene una sola hebra ... en la primera línea de ejemplo uno hace uso de una costosa y bloqueante operación de E/S. La línea 2 no se puede ejecutar hasta que se complete la línea uno. ¿Esto es porque la línea 2 requiere información de la línea 1? ¿O es porque los eventos de E/S son simplemente operaciones de bloqueo fundamentales, lo que significa que se apoderan del control y no lo devuelven hasta que se hace ...
En el segundo ejemplo, la costosa E/S se ha movido a una función, y ahora tenemos una función de devolución de llamada. Ciertamente, la devolución de llamada no se puede ejecutar hasta que se complete la E/S. Esto no cambiaría. Entonces, la diferencia en la cantidad de tiempo que se tarda en ejecutar entre uno y dos debe ser principalmente lo que sucedería si una segunda solicitud llega al servidor.
Si una segunda solicitud golpea el ejemplo uno, no podría procesarse hasta que se haya realizado la solicitud 1 debido a la operación de bloqueo ... pero en el ejemplo dos ... ¿las operaciones en movimiento en funciones generan automáticamente procesos secundarios o actúan como multihilo? Si Javscript tiene un único subproceso, esto aún representaría un problema a menos que haya alguna forma de hacer un procesamiento paralelo. ¿Una función/devolución de llamada solo garantiza ser no bloqueante SI hacemos uso de técnicas sin bloqueo como procesos secundarios, etc.
Gracias por la gran analogía. Para mayor aclaración. En este ejemplo, un cajero toma una orden y la devuelve a la cocina, luego puede ir y procesar otra orden. Ahora, quien toma la orden aquí es la función principal del servidor ... y la cocina son todas las funciones delegadas con sus propias devoluciones de llamada. Si la función de servidor delega en una función y les devuelve una devolución de llamada y dice ... vuelve a consultarme cuando haya terminado ... Si a la cocina no se le da un medio para generar un proceso secundario ... ¿no se bloqueará hasta que se realice la devolución de llamada? ¿se ha enviado? – Inc1982
La cocina tiene un grupo de subprocesos interno. Por lo tanto, tendrá algunos hilos para distribuir las tareas. Pero esto está abstraído de usted en Node.js, y nada de eso se ejecuta en su ciclo de eventos, por lo que no afectará en absoluto su código. Si realiza un cálculo intensivo de CPU en su propio código, eso bloqueará _el ciclo completo del evento_ (por ejemplo, digamos que el cajero decide hornear uno de los panes él mismo), durante este tiempo, no puede tomar ningún pedido nuevo). –
¿Está diciendo que para una función estándar/nodo de devolución de llamada puede usar un grupo de subprocesos interno para garantizar el rendimiento asincrónico pero que para una llamada costosa, tendríamos que configurar un trabajador como lo haría el ejecutivo? Si es así, ¿cómo sabría el umbral de 'caro'? Ese parece ser un punto clave entonces. – Inc1982