15. I/O assíncrono e multiplexação

Este capítulo nasce das 30 questões publicadas sobre I/O assíncrono e multiplexação. A leitura do acervo revelou 30 núcleos de conhecimento, aqui reorganizados como uma explicação progressiva: primeiro o vocabulário e o modelo mental, depois os mecanismos, as decisões de implementação, os limites e a forma de verificar o comportamento do sistema.

Com modelos e componentes definidos, estudamos tarefas que avançam no tempo e disputam recursos. Ordem, estado compartilhado, sincronização, cancelamento e falhas precisam ser analisados em conjunto. Este é o capítulo 15 de 20 da disciplina Programação Assíncrona e Concorrência. Ele retoma Event loop e execução orientada a eventos e utiliza essa base para avançar. Na sequência, estudaremos Corrotinas e geradores.

O fio condutor

O desenvolvimento de software começa com um problema e avança por decisões que precisam permanecer compreensíveis e verificáveis. Requisitos orientam modelos; modelos orientam código e arquitetura; testes verificam comportamento; e a operação devolve informações para o próximo ciclo. Uma falha importante no início tende a se espalhar pelas etapas seguintes.

Neste capítulo, use I/O assíncrono e multiplexação para acompanhar quatro perguntas: qual problema precisa ser resolvido, como o mecanismo funciona, que consequências a escolha produz e como o resultado será verificado. Essa sequência transforma termos técnicos em decisões que podem ser explicadas e testadas.

Parte 1 — Fundamentos e vocabulário

Começamos por Parte 1 — Fundamentos e vocabulário, pois essa base organiza os conceitos e exemplos que aparecerão no restante do capítulo.

Multiplexação

O ponto de partida é estabelecer o significado do conceito e o problema que ele procura organizar. A multiplexação reúne o acompanhamento de muitos descritores em uma interface de espera, como select, poll, epoll ou kqueue. Quando o sistema operacional informa atividade, a thread despacha o tratamento dos descritores correspondentes. Isso reduz a necessidade de manter uma thread bloqueada por conexão e foi decisivo para servidores com grande número de sockets. A técnica não elimina o trabalho de processar os dados nem torna automaticamente paralela a aplicação. A regra ganha sentido quando suas consequências orientam a implementação.

Para aplicar Multiplexação, acompanhe a execução desde a entrada até a saída e anote pré-condições, mudança de estado, custo e falhas possíveis. Assim o conceito deixa de ser um rótulo e passa a orientar decisões.

Use como teste da compreensão: A multiplexação de I/O permite que uma única thread acompanhe vários descritores e trate apenas aqueles que estejam prontos, em vez de bloquear uma thread para cada conexão. Depois verifique a afirmação com execução controlada, teste automatizado, análise do contrato, medição ou documentação da versão correspondente. A evidência deve reproduzir a propriedade afirmada, inclusive nos casos de erro e de fronteira.

Select e poll têm interfaces distintas e não compartilham necessariamente o mesmo limite

A partir dessa distinção, o próximo elemento completa o fluxo. Select e poll têm interfaces distintas e não compartilham necessariamente o mesmo limite numérico de descritores. select costuma ser condicionado por FD_SETSIZE e por conjuntos de bits, enquanto poll recebe uma lista de estruturas sem esse limite fixo de interface. Entretanto, nas formas tradicionais, ambos exigem percorrer ou reconstruir conjuntos proporcionais ao número de descritores monitorados. A notificação focada nos descritores que ficaram prontos é característica associada a mecanismos como epoll e kqueue, não uma propriedade de select e poll. Observe como definição, mecanismo e efeito permanecem ligados.