Evento impulsado y asincrónico a menudo se utilizan como sinónimos. ¿Hay alguna diferencia entre los dos?¿Cuál es la diferencia entre controlado por eventos y asincrónico? Entre epoll y AIO?
Además, ¿cuál es la diferencia entre epoll y aio? ¿Cómo encajan?
Por último, he leído muchas veces que AIO en Linux está terriblemente roto. ¿Cómo está roto?
Gracias.
Eventos es uno de los paradigmas para lograr la ejecución asincrónica. Pero no todos los sistemas asincrónicos usan eventos. Se trata del significado semántico de estos dos: uno es la súper entidad de otro.
epoll y AIO utilizan diferentes metáforas:
epoll es una operación de bloqueo (epoll_wait()) - bloquea el hilo hasta que ocurre algún evento y luego distribuir el evento a diferentes procedimientos/funciones/ramas en el código.
En AIO, pasa la dirección de la función de devolución de llamada (rutina de finalización) al sistema y el sistema llama a su función cuando sucede algo.
El problema con AIO es que el código de la función de devolución de llamada se ejecuta desde el hilo del sistema y, por lo tanto, encima de la pila del sistema. Algunos problemas con eso como te puedes imaginar.
Evento accionado es un hilo único donde se registran eventos para un escenario determinado. Cuando se enfrenta ese escenario, los eventos se disparan. Sin embargo, incluso en ese momento, cada uno de los eventos se dispara de forma secuencial. No hay nada asíncrono al respecto. Node.js (servidor web) usa eventos para tratar múltiples solicitudes.
Asincrónico es básicamente multitarea. Puede generar múltiples hilos o procesos para ejecutar una determinada función. Es totalmente diferente al evento impulsado en el sentido de que cada hilo es independiente y apenas interactúa con el hilo principal de una manera fácil y receptiva. Apache (servidor web) utiliza varios subprocesos para tratar las solicitudes entrantes.
Son cosas completamente diferentes.
El paradigma impulsado por eventos significa que un objeto llamado "evento" se envía al programa siempre que sucede algo, sin que ese "algo" tenga que ser sondeado en intervalos regulares para descubrir si ha sucedido. Ese "evento" puede quedar atrapado por el programa para realizar algunas acciones (es decir, un "controlador"), ya sea sincrónico o asíncrono.
Por lo tanto, la gestión de eventos puede ser sincrónica o asincrónica. JavaScript, por ejemplo, usa un sistema de eventos sincrónicos.
Asincrónico significa que las acciones pueden suceder independientemente de la corriente de ejecución "principal" actual. Eso sí, lo hace NO significa "paralelo" o "hilo diferente". Una acción "asíncrona" puede ejecutarse en el hilo principal, bloqueando la secuencia de ejecución "principal" mientras tanto. Por lo tanto, no confunda "asincrónico" con "multi-threading".
Usted puede decir que, técnicamente hablando, una operación asíncrona automáticamente asume concurso completo - al menos "completado", eventos "abortados/cancelados" (uno o más de estos) "falla" o se envían al instigador de la operación (o la propia O/S subyacente) para indicar que la operación ha cesado. Por lo tanto, asincrónica siempre se basa en eventos, pero no al revés.
Usted dice: "Tenga en cuenta que NO significa" paralelo "o" hilo diferente ". ¿Puedes explicar más con un ejemplo? Si el evento se maneja dentro del hilo principal, ¿cómo es independiente de la corriente de ejecución principal actual? –
Ciertos sistemas de software implementan rutinas conjuntas, por ejemplo, que permite alternar entre flujos de ejecución dentro del mismo hilo. Sin embargo, otros sistemas pueden "adelantarse" a la operación actual al recibir un evento, ejecutar el controlador y luego reanudar la ejecución de la secuencia original, todo dentro de la misma secuencia: pensar interrupciones. Algunos sistemas no son compatibles con ninguno de estos y requieren que los eventos sean "almacenados", esperando que el hilo principal finalice su operación actual y luego explícitamente "busquen" - piensen en JavaScript y en el bucle de mensajes de Windows. –
Hola Stephen, creo que el controlador de singles de Linux es una instancia de co-rutinas en este escenario. ¿Es correcto? – firo
Imagina subprocesos que permiten un comportamiento asincrónico independiente del uso de una arquitectura basada en eventos. Las arquitecturas basadas en eventos a menudo permiten que el programa "viva dentro de un contenedor" (por ejemplo, un hilo, un proceso, etc., que puede mantener algunas tareas simples) pero no excluyen otras técnicas asincrónicas de "contenedor cruzado". –