E/S bloqueante versus não bloqueante

Uma chamada de sistema bloqueante suspende a thread chamadora até que a operação possa prosseguir. Quando o senhor chama recv() em um soquete sem dados, o núcleo estaciona sua thread até a chegada dos bytes.

É simples raciocinar sobre isso: uma conexão, uma thread, código linear. O custo aparece quando é necessário atender milhares de clientes ao mesmo tempo.

Com E/S bloqueante, um cliente travado bloqueia toda a thread. A solução clássica é usar uma thread (ou processo) por conexão.

Isso funciona até certo ponto, mas 10.000 threads significam 10.000 pilhas, muita troca de contexto e sobrecarga do escalonador. Esse é o famoso problema C10k, que levou os servidores a adotar arquiteturas orientadas a eventos.

Um soquete não bloqueante nunca dorme. Se uma chamada não puder ser concluída imediatamente, ela retorna -1 na hora e define errno como EAGAIN ou EWOULDBLOCK.

Agora seu código é responsável por tentar novamente mais tarde. Isso permite que uma única thread gerencie muitos soquetes sem ficar presa em nenhum deles.

O senhor muda um descritor para o modo não bloqueante adicionando a flag O_NONBLOCK com fcntl(). Sempre leia primeiro as flags atuais e depois faça OR com o bit, para não eliminar outras configurações.

Esse mesmo auxiliar é usado igualmente em soquetes de escuta, soquetes de clientes aceitos e pipes.

A E/S não bloqueante torna as operações parciais normais. Um recv() pode retornar menos bytes do que o solicitado, e send() pode aceitar apenas parte do seu buffer.

É necessário acompanhar quanto foi enviado ou recebido e continuar a partir desse ponto. Nunca presuma que uma chamada move todos os bytes.

A maneira ingênua de usar soquetes não bloqueantes é percorrer todos eles em um laço, tentando novamente sem parar. Essa espera ocupada consome 100% da CPU mesmo quando nada acontece.

O que realmente queremos é perguntar ao núcleo: "informe quais descritores estão prontos e deixe-me dormir até lá". É exatamente isso que a notificação de prontidão oferece.

A multiplexação de E/S permite que uma thread espere por muitos descritores ao mesmo tempo e acorde somente quando pelo menos um estiver pronto. O núcleo faz o monitoramento por nós.

As interfaces clássicas são select() e poll(). Elas funcionam, mas reexaminam todos os descritores a cada chamada, o que fica caro em grande escala.

Tanto select() quanto poll() são O(n): cada chamada passa o conjunto completo de descritores ao núcleo, que examina todos; depois o senhor examina todos novamente para encontrar os que estão prontos.

select() também fica limitado por volta de FD_SETSIZE (frequentemente 1024). Para milhares de conexões, essa sobrecarga predomina.

epoll é a solução escalável do Linux. O senhor registra o interesse em um descritor uma vez, e o núcleo mantém uma estrutura de dados interna que acompanha a prontidão.

Cada espera retorna apenas os descritores que realmente estão prontos, portanto o custo cresce com as conexões ativas, não com o total de conexões. Isso o torna aproximadamente O(1) por evento pronto.

epoll e soquetes não bloqueantes trabalham em conjunto. epoll informa que um descritor está pronto; as chamadas não bloqueantes permitem esvaziá-lo sem nunca dormir.

O senhor deve sempre definir O_NONBLOCK nos soquetes entregues ao epoll. Caso contrário, uma ativação espúria ou uma leitura parcial poderá bloquear sua única thread do laço de eventos.

Imagine o servidor como um laço: bloqueie em epoll_wait(), receba uma pequena lista de descritores prontos, faça trabalho não bloqueante em cada um e repita.

A thread dorme quando está ociosa e acorda apenas para trabalho real. Agora uma thread pode atender dezenas de milhares de conexões com eficiência.

Teste sua compreensão sobre soquetes não bloqueantes.

A E/S bloqueante é simples, mas ocupa uma thread por conexão, o que falha em grande escala. A E/S não bloqueante retorna imediatamente com EAGAIN em vez de dormir.

Consultar soquetes em um laço apertado desperdiça CPU, por isso usamos a notificação de prontidão. select/poll são O(n); epoll escala para muitos milhares de conexões. Agora configuraremos o epoll.