Bucle de eventos

Una página web y su código JavaScript suelen ejecutarse en un proceso de navegador web de un solo hilo . Este proceso procesa los mensajes de una cola uno a uno. Cada mensaje puede estar asociado a una función JavaScript u otro evento del navegador. Cuando el navegador termina de procesar un mensaje, pasa al siguiente de la cola.

En entornos JavaScript, el bucle de eventos trabaja con colas separadas —incluida una cola de tareas y una cola de microtareas— para gestionar operaciones asíncronas como temporizadores, devoluciones de llamada de promesas y eventos DOM. Cuando la pila de llamadas está vacía, el bucle de eventos selecciona la siguiente tarea de estas colas para ejecutarla. ^{[ 2 ]}

En Windows , un proceso que interactúa con el usuario debe aceptar y responder a los mensajes entrantes, lo cual se realiza casi inevitablemente mediante un bucle de mensajes dentro de dicho proceso. En Windows, un mensaje se equipara a un evento creado e impuesto al sistema operativo. Un evento puede ser la interacción del usuario, el tráfico de red, el procesamiento del sistema, la actividad del temporizador, la comunicación entre procesos, entre otros. Para eventos no interactivos, de solo E/S, Windows cuenta con puertos de finalización de E/S . Los bucles de los puertos de finalización de E/S se ejecutan de forma independiente del bucle de mensajes y, por defecto, no interactúan con él.

El núcleo de la mayoría de las aplicaciones Win32 es la función WinMain() , que llama a GetMessage() en un bucle. GetMessage() se bloquea hasta que se recibe un mensaje (evento) (con la función PeekMessage() como alternativa no bloqueante). Tras un procesamiento opcional, llama a DispatchMessage() , que distribuye el mensaje al controlador correspondiente, también conocido como WindowProc . Normalmente, los mensajes que no tienen un WindowProc() específico se distribuyen a DefWindowProc , el predeterminado. DispatchMessage() llama al WindowProc del identificador HWND del mensaje (registrado con la función RegisterClass() ).

Las versiones más recientes de Windows garantizan que los mensajes se entregarán al bucle de mensajes de una aplicación en el orden en que fueron percibidos por el sistema y sus periféricos. Esta garantía es esencial al considerar las consecuencias del diseño de aplicaciones multihilo . Sin embargo, algunos mensajes tienen reglas diferentes, como los que siempre se reciben al final o los que tienen una prioridad documentada distinta. ^{[ 3 ]}

Las aplicaciones X que utilizan Xlib directamente se construyen en torno a la XNextEventfamilia de funciones; XNextEventse bloquean hasta que aparece un evento en la cola de eventos, momento en el que la aplicación lo procesa adecuadamente. El bucle de eventos de Xlib solo maneja eventos del sistema de ventanas; las aplicaciones que necesitan poder esperar en otros archivos y dispositivos podrían construir su propio bucle de eventos a partir de primitivas como ConnectionNumber, pero en la práctica tienden a usar multihilo .

Muy pocos programas utilizan Xlib directamente. En el caso más común, los kits de herramientas GUI basados ​​en Xlib suelen admitir la adición de eventos. Por ejemplo, los kits de herramientas basados ​​en Xt Intrinsics tienen XtAppAddInput()y XtAppAddTimeout().

No es seguro llamar a funciones de Xlib desde un manejador de señales, porque la aplicación X puede haber sido interrumpida en un estado arbitrario, por ejemplo, dentro de XNextEvent. Verpara una solución para X11R5, X11R6 y Xt.

El bucle de eventos de GLib se creó originalmente para su uso en GTK , pero ahora también se utiliza en aplicaciones sin interfaz gráfica, como D-Bus . El recurso consultado es la colección de descriptores de archivo que interesan a la aplicación; el bloque de consulta se interrumpirá si llega una señal o si expira un tiempo de espera (por ejemplo, si la aplicación ha especificado un tiempo de espera o una tarea inactiva). Si bien GLib cuenta con soporte integrado para eventos de terminación de descriptores de archivo y procesos secundarios, es posible agregar una fuente de eventos para cualquier evento que pueda gestionarse mediante un modelo de preparación, verificación y despacho.

Las bibliotecas de aplicaciones basadas en el bucle de eventos de GLib incluyen GStreamer y los métodos de E/S asíncronos de GnomeVFS , pero GTK sigue siendo la biblioteca cliente más visible. Los eventos del sistema de ventanas (en X , leídos desde el socket X ) son traducidos por GDK a eventos GTK y emitidos como señales de GLib en los objetos widget de la aplicación.

Se permite exactamente un bucle CFRunLoop por hilo, y se pueden conectar tantas fuentes y observadores como se desee. Las fuentes se comunican con los observadores a través del bucle de ejecución, que se encarga de organizar la cola y el envío de mensajes.

En Cocoa, el CFRunLoop se abstrae como un NSRunLoop, lo que permite que cualquier mensaje (equivalente a una llamada a una función en entornos de ejecución no reflexivos ) se ponga en cola para su envío a cualquier objeto.

En Unix , el paradigma de que todo es un archivo da lugar a un bucle de eventos basado en archivos. La lectura y escritura de archivos, la comunicación entre procesos, la comunicación de red y el control de dispositivos se realizan mediante E/S de archivos, donde el destino se identifica mediante un descriptor de archivo . Las llamadas al sistema `select` y `poll` permiten monitorizar un conjunto de descriptores de archivo para detectar cambios de estado, por ejemplo, cuando hay datos disponibles para su lectura.

Por ejemplo, consideremos un programa que lee un archivo que se actualiza continuamente y muestra su contenido en el Sistema X Window , que se comunica con los clientes a través de un socket (ya sea de dominio Unix o Berkeley ):

def main (): file_fd = open ( "logfile.log" ) x_fd = open_display () construct_interface () while True : rlist , _ , _ = select.select ([ file_fd , x_fd ], [ ] , []): if file_fd in rlist : data = file_fd.read ( ) append_to_display ( data ) send_repaint_message () if x_fd in rlist : process_x_messages ( )

En Unix, una señal es un evento asíncrono que es gestionado por un manejador de señales que se ejecuta mientras el resto de la tarea está suspendida. Si se recibe y se gestiona una señal mientras la tarea está bloqueada select(), la instrucción select devolverá EINTR ; si se recibe una señal mientras la tarea está limitada por la CPU , la tarea se suspenderá entre instrucciones hasta que el manejador de señales devuelva un valor.

Una forma de gestionar una señal es que los manejadores de señales establezcan un indicador global y que el bucle de eventos compruebe dicho indicador inmediatamente antes y después de la select()llamada; si está establecido, se gestiona la señal del mismo modo que con los eventos en los descriptores de archivo. Desafortunadamente, esto genera una condición de carrera : si una señal llega inmediatamente entre la comprobación del indicador y la llamada select(), no se gestionará hasta select()que la función devuelva un resultado por algún otro motivo (por ejemplo, si un usuario frustrado la interrumpe).

La solución a la que llegó POSIX es la pselect()llamada, que es similar a select()pero toma un sigmaskparámetro adicional, que describe una máscara de señal . Esto permite que una aplicación enmascare señales en la tarea principal, luego elimine la máscara durante la duración de la select()llamada de modo que los manejadores de señales solo se llamen mientras la aplicación está limitada por E/S . Sin embargo, las implementaciones de pselect()no siempre han sido confiables; las versiones de Linux anteriores a 2.6.16 no tienen una pselect()llamada al sistema, ^{[ 4 ]} forzar a glibc a emularla a través de un método propenso a la misma condición de carrera pselect()se pretende evitar.

Una solución alternativa y más portátil consiste en convertir eventos asíncronos en eventos basados ​​en archivos utilizando el truco de la tubería propia , ^{[ 5 ]} donde "un manejador de señales escribe un byte en una tubería cuyo otro extremo es monitoreado select()en el programa principal". ^{[ 6 ]} En la versión 2.6.22 del kernel de Linux , se agregó una nueva llamada al sistema signalfd()que permite recibir señales a través de un descriptor de archivo especial.

En entornos como navegadores web y Node.js, el bucle de eventos es fundamental para el comportamiento asíncrono de los programas. JavaScript se ejecuta en un único hilo, pero los entornos anfitriones proporcionan API para operaciones no bloqueantes, como temporizadores, solicitudes de red y eventos de usuario. Las operaciones asíncronas completadas se colocan en colas, y el bucle de eventos comprueba repetidamente si la pila de llamadas está vacía para programar las devoluciones de llamada en cola. Esto permite que las aplicaciones JavaScript sigan respondiendo mientras gestionan múltiples tareas asíncronas. ^{[ 7 ]}