Sé que nodejs usa el grupo de subprocesos proporcionado por libuv para realizar trabajos simultáneos. Leí que nodejs solo necesita uno de esos subprocesos para realizar todas las actividades vinculadas de E/S
Entonces, ¿cómo suceden las operaciones de archivos sin bloqueo?
¿Qué sucederá realmente debajo del capó entre el nodo, el disco y el sistema operativo, si itero sobre una carpeta que contiene 100 archivos y los abro todos usando readFile ()?
Si hacer esta misma operación en algún otro lenguaje multiproceso y de bloqueo resultará en subprocesos esperando a que finalice la E/S, entonces, ¿quién espera a que finalice la E/S en nodejs? , especialmente cuando hay múltiples operaciones de archivo que ocurren simultáneamente?
Gracias !
El archivo IO en nodejs usa un grupo de subprocesos. De forma predeterminada, hay 4 subprocesos en el grupo.
Cuando algún Javascript llama a una operación de archivo como fs.open() en nodejs, la llamada se enruta a algún código nativo dentro de la biblioteca libuv en la implementación de nodejs. Ese código agrega la operación de archivo específica a una cola de elementos que esperan un subproceso del sistema operativo. Si un subproceso del sistema operativo está disponible de inmediato, a ese subproceso del sistema operativo se le asigna la tarea de llevar a cabo la operación del archivo y luego regresa la función libuv original, que regresa al Javascript original y nodejs continúa ejecutando otro Javascript.
Luego, algún tiempo después, el subproceso finaliza la operación del archivo y tiene un resultado. Inserta un evento en la cola de eventos de nodejs con el resultado completo y la devolución de llamada original pasada con la operación de archivo original.
Cuando nodejs ha terminado de ejecutar cualquier otro Javascript que estaba ejecutando, extrae el siguiente evento de la cola de eventos y llama a la devolución de llamada de Javascript asociada con ese evento y le pasa los datos asociados con el evento. Esto desencadena la devolución de llamada de Javascript que se pasó originalmente a fs.open() para recibir la llamada.
Si, en el segundo paso anterior, no había subprocesos disponibles en el grupo de subprocesos, entonces la tarea se agrega a una cola y libuv inmediatamente devuelve el control a nodejs para que pueda ejecutar otro Javascript. Algún tiempo después, cuando uno de los subprocesos existentes en el grupo se complete y finalice su trabajo de agregar un evento a la cola de eventos, extraerá el siguiente elemento de la cola del grupo de subprocesos, le dará el subproceso ahora disponible y lo dejará. comenzar a ejecutar su operación.
De esta manera, todas las operaciones de archivo parecen no bloquear y ser asincrónicas desde el lado de Javascript. Se inician inmediatamente si hay un subproceso disponible en el grupo de subprocesos o se sientan en una cola de grupo de subprocesos hasta que haya un subproceso disponible. Esa parte es invisible para el lado de Javascript de las cosas. De cualquier manera, la operación se inicia o se pone en cola y el control regresa inmediatamente a nodejs para continuar ejecutando otro Javascript. Y, de cualquier manera, la operación se completa más tarde y la devolución de llamada de Javascript asociada con la operación del archivo se llama a través de la cola de eventos de Javascript. Esto proporciona el mecanismo asincrónico, sin bloqueo y controlado por eventos que utiliza nodejs para todas las E/S de archivos.