Lanzamiento de Node.js 10.5: multihilo fuera de la caja

La semana pasada, se lanzó Node.js versión 10.5.0, que contiene una innovación cuya importancia difícilmente se puede sobreestimar: soporte de subprocesos múltiples en forma del módulo worker_threads . Inmediatamente haré una reserva. La API está en la etapa experimental y, por lo tanto, puede cambiar, pero ahora puede dar una primera impresión y tener una idea de los principios y tecnologías establecidos en su base. Y si lo desea, participe en finalizar la interfaz, escribir código o corregir errores (lista de problemas ).

Historia de la apariencia

A lo largo de la vida de Node.js, la única forma de paralelizar la informática era comenzar un nuevo proceso, por ejemplo, utilizando el módulo de clúster. Por muchas razones, este enfoque no es adecuado para los desarrolladores, en particular porque conduce a la carga repetida de código ejecutable de Node.js con todos los módulos integrados en la memoria de la computadora, que es una forma ineficiente de gastar recursos.

Sin embargo, la discusión sobre la implementación de subprocesos múltiples en Node.js siempre se basó en la complejidad de V8 y una gran cantidad de incógnitas: cómo conectar módulos nativos, compartir memoria, comunicarse entre subprocesos y más. Y mientras los desarrolladores buscaban qué lado abordar el tema en la web, la API del trabajador se implementó con éxito, lo que se convirtió en una guía en las etapas iniciales. El desarrollo comenzó con addaleax y ha sido asumido por la comunidad.

El trabajo activo se llevó a cabo durante el año, durante el cual se especificaron los requisitos de diseño y la API adquirió sus propias características específicas de Node.js, y el módulo en sí se denominó trabajador_procesos. A continuación, describiré brevemente los hilos de trabajo en términos generales, y para un estudio detallado, le aconsejo que visite la página de documentación oficial .

Descripción

Como se mencionó anteriormente, el objetivo de este desarrollo es mejorar la productividad mediante la distribución de la carga a través de subprocesos separados dentro del mismo proceso, en lugar de iniciar varios procesos. Por lo tanto, los hilos admitirán la conexión de todos los módulos disponibles para el proceso principal (actualmente, los módulos nativos no son compatibles).

Al igual que en la API de Worker, la interacción entre la secuencia principal y la secundaria se lleva a cabo mediante la transferencia de objetos transferibles a través de postMessage, lo que evita los problemas de acceso simultáneo, aunque requiere accesos de memoria adicionales para copiar datos. En este caso, los objetos como SharedArrayBuffer conservan su comportamiento y no causan la reasignación.

MessageChannel y MessagePort se tomaron de WebAPI , que le permite crear canales de mensajería aislados y transferirlos entre hilos.

Para probar worker_threads en acción, cuando inicie el proceso, debe especificar un indicador especial:

node --experimental-worker main.js 

Ejemplo

Dado que la API aún puede cambiar, no lo describiré, pero daré un ejemplo de un intercambio de mensajes entre los hilos principal y secundario, en el que el hilo secundario informa su threadId a través de MessagePort y sale.

Corriente principal

Código de ejemplo para el hilo principal:

 // main.js const {Worker} = require('worker_threads'); const worker = new Worker(__dirname + '/worker.js'); worker.on('online', () => { console.log('Worker ready'); }); worker.on('message', (msg) => { console.log('Worker message:', msg); }); worker.on('error', (err) => { console.error('Worker error:', err); }); worker.on('exit', (code) => { console.log('Worker exit code:', code); }); 

Stream infantil

El subproceso hijo vive hasta que su bucle de eventos esté vacío. Por lo tanto, inmediatamente después de que worker.js el código de worker.js hilo se cerrará automáticamente. Para comunicarse con el padre, se utiliza parentPort:

 // worker.js const {threadId, parentPort} = require('worker_threads'); parentPort.postMessage(`Hello from thread #${threadId}.`); // Exit happens here 

En el subproceso secundario, el objeto del proceso se reemplaza y su comportamiento es ligeramente diferente del comportamiento del proceso en el subproceso principal. En particular, no hay forma de responder a las señales de SIGNINT, cambiar los valores de process.env y llamar a process.exit detendrá solo a los trabajadores, pero no a todo el proceso.

Conclusión

Los trabajadores simplificarán en gran medida la creación de aplicaciones que requieren interacción entre secciones de código ejecutables paralelas y, lo que es especialmente importante, hace que la comunicación y el control de flujo sean la forma más obvia. Y también permitirá evitar restricciones específicas de la plataforma causadas por la diferencia entre Windows y Unix. Estoy seguro de que las oportunidades que se abrirán atraerán a nuevos desarrolladores que aún no han optado por Node.js. Mientras tanto, continúe monitoreando los cambios y conéctese al proceso de desarrollo de API en el repositorio .

Referencias

• Documentación de hilos de trabajo .
• Foto de Paul Smith.