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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]Aplicações Windows
[editar | editar código-fonte]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
[editar | editar código-fonte]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
- ↑ «WinMain Function». Win32 and COM Development (em inglês). Microsoft Developer Network. Consultado em 27 de junho de 2008
- ↑ «GetMessage Function». Win32 and COM Development (em inglês). Microsoft Developer Network. Consultado em 27 de junho de 2008
- ↑ «DispatchMessage Function». Win32 and COM Development (em inglês). Microsoft Developer Network. Consultado em 27 de junho de 2008