design - nodejs - Bloqueo de IO frente a IO no bloqueante; Buscando buenos artículos
nodejs main loop (3)
Bloquear bien IO significa que un hilo determinado no puede hacer nada más hasta que el IO se reciba por completo (en el caso de los sockets, esta espera podría demorar mucho tiempo).
IO sin bloqueo significa que una solicitud de IO se pone en cola directamente y la función vuelve. El IO real se procesa en un puntero posterior por el núcleo.
Para bloquear IO, debe aceptar que va a esperar cada solicitud de IO o va a necesitar despedir un hilo por solicitud (lo que se complicará muy rápidamente).
Para IO no bloqueante puede enviar múltiples solicitudes, pero debe tener en cuenta que los datos no estarán disponibles hasta un punto "posterior". Esta comprobación de que los datos realmente han llegado es probablemente la parte más complicada.
En el 99% de las aplicaciones, no necesitará preocuparse por sus bloques IO. A veces, sin embargo, necesita el rendimiento adicional de permitirse iniciar una solicitud de IO y luego hacer otra cosa antes de regresar y, con suerte, encontrar que la solicitud de IO se ha completado.
De todos modos, solo mi tuppence.
Hubo un tiempo en que me topé con el artículo de introducción a Indy y no puedo dejar de pensar en el bloqueo frente al IO sin bloqueo desde entonces.
Buscando algunos buenos artículos que describan cuáles son los pros y los contras de bloquear IO y IO no bloqueante y cómo diseñar su aplicación en cada caso para obtener un código natural, fácil de entender y fácil de mantener.
Me gustaría entender una GRAN imagen ...
Los aspectos positivos y negativos son bastante claros:
Bloqueo: programación lineal, más fácil de codificar, menos control.
Sin bloqueo: programación en paralelo, más difícil de codificar, más control.
No he encontrado buenos artículos.
He pedido aquí sugerencias sobre cómo diseñar código IO asíncrono: código de ordenamiento para IO asíncrono
Las respuestas en realidad no fueron muy cálidas.
Async IO es una bestia para resolver problemas y depurar, especialmente si usa desencadenantes de borde (por ejemplo, epoll de Linux con indicador EPOLLET). Pero es lo que paga por la complejidad del código que gana en rendimiento y escalabilidad.