Laço de eventos

Em ciência da computação, um laço de eventos ou laço de mensagens é uma construção de programação que espera eventos e mensagens e as despacha num programa de computador. O mecanismo é um laço infinito que é bloqueado até que chegue um evento, que então é tratado (despachado). O mecanismo então é reiniciado. Quando presente, esta construção é frequentemente o controle de fluxo central do programa, podendo então ser chamada laço principal.

O laço de eventos pode ser considerado uma ferramenta para a comunicação entre processos, sendo uma implementação específica de sistemas que usam troca de mensagens.

Alternativas

Existem diversas alternativas ao uso do laço de mensagens. Tradicionalmente, um programa pode simplesmente ser executado e terminar. Qualquer parâmetro é configurado antes da execução do algoritmo. Apesar de ter sido mais frequente no início da computação, essa técnica ainda é usada em alguns programas de linha de comando. Outra alternativa também usada por programas de linha de comando são menus. Ainda que a implementação interna possa usar um laço principal, essa técnica não é considerada como orientada a eventos.

Uso

Devido a predominância das interfaces gráficas, a maioria das aplicações atuais apresentam um laço principal. A rotina obtenha_próxima_mensagem() é geralmente fornecida pelo sistema operacional, e bloqueia a thread até que a mensagem esteja disponível. Portanto, o processamento é feito somente quando necessário. Segue abaixo um pseudocódigo dum laço de eventos:

ROTINA principal
    inicializa()
    ENQUANTO VERDADEIRO # laço infinito
        mensagem ← obtenha_próxima_mensagem()
        SE mensagem = sair ENTÃO
            RETORNE
        FIMSE
        processa_mensagem(mensagem)
    FIMENQUANTO
FIMROTINA

Interface de arquivo

Em Unix, a forma de tratamento de recursos como arquivos levou naturalmente a um laço de eventos baseado em arquivos. Ler e escrever arquivos, a comunicação entre processos, comunicação por redes e o controle de dispositivos Sào todos feitos através de E/S de arquivos, e a identificação do recurso é feita por um descritor de arquivo. As chamadas de sistema select e poll permitem que um conjunto de descritores e arquivo sejam monitorados quanto a mudança de estado, como para avisar a disponibilidade de escrita ou leitura.

Tratamento de sinais

Uma das interfaces Unix que não são tratadas como arquivos são eventos assíncronos, sinais. Eles são recebidos por uma camada leve e limitada de software que é executada enquanto a tarefa está suspensa. Se um sinal é recebido e tratado enquanto a tarefa está bloqueada numa chamada select(), então select() retornará com o código de erro EINTR; se um sinal é recebido enquanto a tarefa está em processamento, então a tarefa será suspensa entre as instruções até que o sinal seja tratado.

Portanto, para que os sinais sejam tratados deve-se acionar uma indicação global, e o laço de eventos deve verificar essa indicação antes e após a execução da chamada select(); se estiver acionada, o sinal deve ser tratado da mesma forma que eventos em descritores de arquivos. Entretanto, isso gera uma condição de corrida: se o sinal é recebido imediatamente entre a verificação da indicação e a chamada de select(), então ele não será tratado até que select() retorne por qualquer outra razão (por exemplo, fechamento manual de recurso).

Implementações

Aplicações Windows

O sistema operacional Microsoft Windows requer a construção de um laço de eventos para processos que desejam interagir com utilizadores, a fim de responder aos eventos enviados pelo sistema. Eventos enviados pelo sistema operacionais variam desde interação com o usuário até tráfego de rede, processamento do sistema, cronômetro de atividade a comunicação entre processos, entre outros.

Uma das principais características da maioria das aplicações Win32 é a função WinMain[1], que invoca num laço a função GetMessage()[2]. Após invocada, esta última é bloqueada até que uma mensagem (evento) é recebida. Após algum processamento opcional, a função DispatchMessage()[3] é invocada, que despacha a mensagem ao destinatário correto, conhecido como WindowProc.

Versões mais recentes do Windows fornecem a garantia ao programador de que as mensagens serão enviadas ao laço de eventos da ordem em que foram recebidas pelo sistema e seus periféricos, o que relevante no desenvolvimento dum sistema multitarefa.

X Window System

Aplicações X que usam a Xlib diretamente são construídas a partir do conjunto de funções XNextEvent; XNextEvent é bloqueada até que um evento chegue. O laço de eventos da Xlib trata somente dos eventos da interface gráfica. Apliacções que precisam esparar por outros arquivos e dispositivos devem construir seu próprio laço de eventos a partir de primitivas como ConnectionNumber, mas a prática comum é usar multitarefa. Entretanto, poucos programas usam a Xlib diretamente. Na maioria dos casos, ferramentas de interfaces gráficas baseadas na Xlib são usadas para suportar mais eventos.

Já o laço de eventos da Glib foi criado para ser usado em GTK+, mas passou a ser usado também em aplicações que não usam intefaces gráficas, como o D-Bus. Aplicações que são construídas a partir do laço de eventos da Glib incluem o GStreamer e os métodos de comunicação assíncrona do GnomeVFS.

Referências

1. «WinMain Function». Win32 and COM Development (em inglês). Microsoft Developer Network. Consultado em 27 de junho de 2008 
2. «GetMessage Function». Win32 and COM Development (em inglês). Microsoft Developer Network. Consultado em 27 de junho de 2008 
3. «DispatchMessage Function». Win32 and COM Development (em inglês). Microsoft Developer Network. Consultado em 27 de junho de 2008 

Ver também

• Troca de mensagens
• Comunicação entre processos
• Comunicação assíncrona