PHP 8.6 Polling API: por que um resultado quase unânime muda o futuro do async PHP

“Em junho de 2026, uma RFC relacionada ao Polling API se tornou uma das aprovações mais fortes do ciclo do PHP 8.6. E ela tenta resolver um gargalo que existe desde 1983.”

Durante décadas, o PHP foi associado ao modelo clássico de request-response: recebe uma requisição, executa código, devolve HTML e encerra.

Mas o mundo mudou.

Hoje temos aplicações que exigem:

• APIs de alta concorrência
• WebSockets
• Streaming em tempo real
• filas assíncronas
• runtimes persistentes
• aplicações realtime

E o velho mecanismo usado pelo PHP para monitorar conexões simplesmente não acompanha mais essa realidade.

A nova Polling API (Io\Poll) do PHP 8.6 representa uma das mudanças mais importantes da história moderna da linguagem — especialmente para quem trabalha com aplicações assíncronas.

O problema que começou em 1983

Antes de entender o Io\Poll, precisamos falar sobre o inimigo silencioso do async em PHP: o stream_select().

O select() nasceu nos sistemas Unix dos anos 80 e foi oficialmente padronizado em 1983.

Na prática, ele serve para perguntar ao sistema operacional:

“Quais conexões estão prontas para leitura ou escrita?”

Isso funcionou muito bem durante décadas.

O problema é que o modelo envelheceu.

Por que stream_select() virou gargalo

O PHP herdou esse comportamento através de stream_select().

Embora funcional, ele possui limitações sérias.

Limite de descritores (FD_SETSIZE)

Na maioria dos sistemas Unix:

FD_SETSIZE = 1024

Ou seja:

• apenas cerca de 1024 conexões simultâneas
• incluindo sockets internos
• pipes
• conexões TCP
• arquivos

Para aplicações modernas, isso é muito pouco.

Complexidade O(n)

O select() percorre todos os descritores a cada ciclo.

Mesmo conexões inativas precisam ser verificadas.

Resultado:

• mais CPU
• mais latência
• pior escalabilidade

Quanto mais conexões, pior o desempenho.

Escalabilidade ruim

Em workloads modernos com:

• WebSockets
• SSE
• proxies reversos
• APIs realtime

o stream_select() se torna um gargalo rapidamente.

O que é o novo Io\Poll

A nova Polling API introduz uma abstração moderna para multiplexação de I/O.

Ela permite que o PHP utilize mecanismos nativos do sistema operacional:

• Linux → epoll
• BSD/macOS → kqueue
• Windows → WSAPoll

Esses sistemas foram criados justamente para resolver os problemas do select().

A ideia central da Polling API

O objetivo é simples:

monitorar milhares de conexões sem precisar percorrer todas elas continuamente.

Em vez de perguntar:

“essas 50 mil conexões têm atividade?”

o sistema operacional notifica apenas as conexões relevantes.

Isso muda completamente a eficiência do loop assíncrono.

Como epoll, kqueue e WSAPoll funcionam

epoll (Linux)

O epoll é baseado em eventos.

Você registra sockets uma única vez.

Depois disso:

• o kernel monitora tudo
• acorda apenas quando necessário
• evita loops desperdiçando CPU

É o mecanismo usado por:

• Node.js
• Nginx
• Redis
• HAProxy

kqueue (BSD/macOS)

O kqueue segue filosofia semelhante:

• sistema orientado a eventos
• eficiente
• baixo overhead

Muito usado em servidores BSD e ambientes Apple.

WSAPoll (Windows)

O Windows historicamente ficou atrás no ecossistema async.

A Polling API ajuda a aproximar o suporte multiplataforma do PHP.

Por que a aprovação quase unânime importa

RFCs importantes normalmente geram debates intensos.

Especialmente quando mexem com:

• runtime
• I/O
• internals
• concorrência

O apoio massivo mostra algo raro:

existe consenso de que o PHP precisa evoluir seu modelo de I/O.

Isso é significativo porque o ecossistema PHP sempre foi mais conservador em mudanças estruturais.

O impacto direto em runtimes async

A Polling API não transforma automaticamente o PHP em Node.js.

Mas ela entrega uma fundação moderna para ferramentas que já trabalham com async.

ReactPHP

O ReactPHP depende fortemente de loops de eventos.

Hoje ele utiliza abstrações sobre:

• stream_select
• ext-event
• ext-uv

Com Io\Poll, parte dessa complexidade pode desaparecer.

Benefícios esperados:

• menos overhead
• menos dependências externas
• melhor integração nativa
• loops mais eficientes

RoadRunner

O RoadRunner já resolve vários gargalos clássicos do PHP-FPM.

Mas workloads massivos de conexão simultânea ainda dependem bastante da camada Go do projeto.

Com uma infraestrutura async mais madura no core do PHP:

• workers podem ficar mais leves
• integrações realtime ficam mais eficientes
• há menos necessidade de workarounds

Swoole

O Swoole sempre foi a prova de que o PHP podia ser extremamente rápido.

Mas ele depende de extensões complexas em C.

A Polling API aproxima parte dessas capacidades do próprio core da linguagem.

Isso reduz:

• fragmentação
• lock-in de extensão
• dependência de APIs proprietárias

O salto de performance esperado

Os maiores ganhos devem aparecer em:

Importante:

Para aplicações PHP clássicas de request-response, o impacto pode ser pequeno.

O foco real é concorrência massiva.

Comparação com Node.js e Go

Node.js nasceu sobre libuv.

Go possui scheduler próprio e runtime concorrente.

O PHP historicamente ficou preso ao modelo síncrono tradicional.

A Polling API aproxima o PHP da infraestrutura usada por linguagens modernas.

Mas ainda existem diferenças importantes.

O PHP ainda não possui:

• scheduler nativo completo
• async/await oficial
• fibers integradas ao I/O automaticamente

Mas agora existe uma base real para isso evoluir.

Como o Polling API funciona internamente

A API atua como camada de abstração.

Ela:

1. detecta o sistema operacional
2. seleciona o backend ideal
3. registra watchers
4. recebe eventos do kernel
5. despacha callbacks

Fluxo simplificado:

text Socket → Kernel → epoll/kqueue → Io\Poll → Runtime async

Isso reduz drasticamente o custo de monitoramento.

Compatibilidade e adoção

Um dos pontos mais importantes da RFC é que ela não quebra aplicações tradicionais.

Ela é incremental.

Quem usa:

• Laravel
• Symfony
• WordPress
• PHP-FPM

não precisa mudar nada imediatamente.

A adoção acontecerá principalmente em:

• runtimes persistentes
• servidores async
• bibliotecas de networking
• frameworks realtime

Relação com a True Async RFC

Existe uma pergunta inevitável:

o Polling API substitui a ideia de “True Async” no PHP?

Provavelmente não.

Na verdade, ele parece ser um passo intermediário.

O Polling API resolve a infraestrutura de I/O.

Mas ainda faltam:

• async/await oficial
• integração automática com fibers
• scheduler de tasks
• APIs assíncronas padronizadas

Em outras palavras:

o Polling API prepara o terreno.

Limitações atuais

Mesmo sendo revolucionária, a Polling API não resolve tudo.

Ainda existem desafios.

Ecossistema legado

Grande parte das bibliotecas PHP continua síncrona.

Banco de dados

Drivers async ainda são inconsistentes.

Curva de aprendizado

Async muda completamente o modelo mental do desenvolvimento backend.

Compatibilidade entre runtimes

Ainda haverá diferenças entre:

• Swoole
• ReactPHP
• Amp
• RoadRunner

O que muda para desenvolvedores PHP

A principal mudança é filosófica.

O PHP deixa de depender exclusivamente do modelo clássico request-response.

Isso abre portas para:

• aplicações realtime
• game servers
• gateways websocket
• brokers
• proxies
• sistemas distribuídos

Sem precisar abandonar a linguagem.

FAQ — PHP 8.6 Polling API

O Polling API substitui o stream_select()?

Não imediatamente, mas oferece uma alternativa moderna e escalável.

Aplicações Laravel comuns terão ganho?

Provavelmente pouco impacto direto no curto prazo.

Isso transforma PHP em Node.js?

Não. Mas aproxima o PHP de arquiteturas async modernas.

Preciso usar Swoole para aproveitar?

Não necessariamente. Frameworks async poderão usar a nova API diretamente.

O Polling API melhora WebSockets?

Sim. Esse é um dos maiores casos de uso.

A RFC já está aprovada?

As discussões e votações podem ser acompanhadas em:

• https://php.watch/rfcs/poll_api
• https://wiki.php.net/rfc

Por décadas, runtimes como Node.js e Go dominaram workloads altamente concorrentes.

Agora, o PHP começa a construir uma fundação moderna para competir nesse espaço — não apenas através de extensões externas, mas dentro do próprio core da linguagem.

E isso pode redefinir completamente o que significa desenvolver aplicações backend em PHP nos próximos anos.