O Modelo Async do Rust

Async/await em Rust se parece com async/await em JavaScript ou C#, mas o mecanismo subjacente é fundamentalmente diferente, e essa diferença explica a maior parte do comportamento surpreendente que os novatos encontram: futures que "não fazem nada" até serem aguardados (awaited), um erro de compilação mencionando Pin, ou confusão sobre por que async fn main precisa de um macro de atributo. O modelo async do Rust é construído a partir de um único trait, Future, e uma escolha deliberada de não enviar um runtime na biblioteca padrão.

Esta página é a âncora conceitual para o restante da seção async-futures. As outras páginas aqui cobrem mecânicas específicas: o método poll do trait Future, executores, pinning, streams e cancelamento. Esta página as une em um único modelo mental: futures como máquinas de estados preguiçosas, executores como o que as impulsiona, e pinning como uma consequência estrutural de como o compilador constrói essas máquinas de estados.

Resumo

• async fn e blocos async compilam para tipos anônimos que implementam o trait Future, uma máquina de estados que progride apenas quando algo chama poll nela.
• Por que Importa: Este design permite que o Rust execute um grande número de operações concorrentes em um pequeno pool de threads com zero alocação de heap por tarefa por padrão, ao custo de precisar de um runtime externo para realmente executar qualquer coisa.
• Conceitos Chave: Future, poll, executor, waker, máquina de estados, Pin.
• Quando Usar: Entender este modelo é importante sempre que você depurar uma tarefa travada, escolher um runtime, escrever um Future personalizado ou encontrar um erro de compilador Send/Pin que você não reconhece imediatamente.
• Limitações / Trade-offs: O design preguiçoso e sem runtime empurra a complexidade real, o agendamento, a prontidão de I/O, os timers para crates de terceiros, então "Rust async" sempre significa realmente "Rust async mais um runtime".
• Tópicos Relacionados: o contrato poll do trait Future, executores e runtimes, pinning e Unpin, agendamento cooperativo de tarefas.

Fundamentos

O fato mais importante sobre futures do Rust é que eles são preguiçosos. Criar um valor com um bloco async ou chamar uma async fn não faz nenhum trabalho; apenas constrói um valor. O trabalho só acontece quando esse valor é chamado (polled), e chamar (polling) não é algo que o código da aplicação normalmente faz diretamente; um executor faz isso.

Esta é uma departure deliberada das promises do JavaScript, que começam a executar no momento em que são criadas. Um future do Rust é mais próximo de um iterador não iniciado: let fut = fetch_data(); aloca uma máquina de estados e não faz mais nada, exatamente como let iter = vec.iter(); produz um iterador que ainda não tocou em nenhum elemento.

Cada async fn e bloco async é açúcar sintático. O compilador transforma o corpo da função em uma struct anônima que implementa o trait Future, com as variáveis locais do corpo se tornando os campos da struct e cada ponto de .await se tornando um possível estado de pausa. Conceitualmente:

// async fn fetch() -> u32 { let x = step_one().await; step_two(x).await }
// compila para algo como um enum:
enum FetchState {
    Start,
    WaitingOnStepOne { /* captured locals */ },
    WaitingOnStepTwo { x: u32 },
    Done,
}

Esta máquina de estados tem um método que importa: poll, que retorna Poll::Ready(value) quando o trabalho está completo, ou Poll::Pending quando precisa esperar por algo, um byte de rede de entrada, um timer, outro future. async/await é apenas uma maneira conveniente de escrever essa máquina de estados manualmente sem realmente escrever um enum e uma instrução match você mesmo.

Mecânicas e Interações

Um Future não pode se fazer rodar mais rápido por desejo; ele precisa de algo externo a ele chamando poll repetidamente até que retorne Poll::Ready. Esse algo é um executor, e a biblioteca padrão do Rust deliberadamente não fornece um.

Essa divisão é intencional e espelha um padrão mais amplo na linguagem: a biblioteca padrão define o trait (o contrato), e o ecossistema fornece implementações ajustadas para diferentes ambientes. Tokio, async-std, smol e runtimes embarcados como Embassy implementam o mesmo contrato Future de maneiras diferentes, um otimizado para servidores com pools de threads, outro para microcontroladores sem heap. Uma biblioteca que usa apenas async fn e nunca spawna um runtime por si só pode rodar sob qualquer um deles.

Chamar poll por si só seria desperdício se o executor apenas chamasse poll em um loop apertado, então um segundo mecanismo completa o quadro: o waker. Quando um future retorna Poll::Pending, ele recebe um Waker como parte do contexto de polling, e é responsável por chamar esse waker mais tarde, tipicamente de um callback de conclusão de I/O ou um timer, para dizer ao executor "me chame (poll) novamente, eu posso estar pronto agora". Essa passagem de waker permite que um executor estacione uma tarefa eficientemente em vez de ficar rodando em loop, e é o mesmo mecanismo se o future está esperando por um socket TCP ou um timer de cinco segundos.

use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};
 
struct Ready(bool);
impl Future for Ready {
    type Output = ();
    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
        if self.0 { Poll::Ready(()) } else {
            cx.waker().wake_by_ref(); // pede para ser chamado (polled) novamente
            Poll::Pending
        }
    }
}

A assinatura poll acima esconde um detalhe que confunde quase todo mundo na primeira vez que a vê: self: Pin<&mut Self> em vez do &mut self comum. É aqui que o pinning entra em cena, e é uma consequência estrutural direta da transformação da máquina de estados descrita em Fundamentos.

Considere um bloco async que empresta (borrows) uma de suas próprias variáveis locais através de um .await, algo como let buf = [0u8; 64]; let n = reader.read(&mut buf).await; seguido por código posterior que lê buf novamente. A máquina de estados gerada pelo compilador precisa armazenar tanto buf quanto uma referência a buf como campos da mesma struct, o que torna a struct auto-referencial: um campo aponta para dentro de outro campo do mesmo valor. Valores Rust comuns podem ser movidos livremente (um memcpy nos bastidores), mas mover uma struct auto-referencial invalida o ponteiro interno, pois ele passaria a apontar para a antiga localização de memória em vez da nova. Pin<P> é um wrapper de ponteiro que promete ao compilador "o valor por trás deste ponteiro nunca se moverá novamente", que é exatamente a garantia que uma máquina de estados auto-referencial precisa para ser segura (sound).

Considerações Avançadas e Aplicações

A maior parte do código da aplicação nunca escreve Pin explicitamente, porque .await faz o pinning de futures na pilha automaticamente, e isso é por design: pinning é um mecanismo que a linguagem precisa, não uma API com a qual a maioria dos usuários deve interagir diretamente. Ele aparece em três situações recorrentes: implementar um Future manualmente, armazenar um future dentro de um campo de struct (o que requer Pin<Box<dyn Future<...>>> já que um campo de struct não pode ser fixado (pinned) na pilha da mesma forma que uma variável local), e ler um erro de compilador !Unpin, que geralmente significa que um future foi movido depois que algo já começou a chamá-lo (polling).

O auto trait Unpin é a válvula de escape que impede que o pinning seja doloroso para o caso comum. Quase todos os tipos Rust comuns são Unpin, o que significa que movê-los após o pinning é aceitável, pois eles não contêm auto-referências. Apenas máquinas de estados async geradas, e tipos auto-referenciais escritos manualmente, são tipicamente !Unpin, e apenas esses realmente precisam da disciplina que Pin impõe.

Runtimes constroem modelos de agendamento e I/O significativamente diferentes sobre o mesmo contrato Future, e a escolha tem consequências operacionais reais, não apenas diferenças de API.

O design preguiçoso e baseado em poll tem consequências diretas para o cancelamento, o que vale a pena nomear explicitamente porque difere do cancelamento baseado em threads. Soltar (dropping) um future em qualquer ponto de await simplesmente para de chamá-lo (polling), não há sinal entregue para "interromper" o trabalho em andamento da maneira que uma thread pode receber um sinal. Isso torna o cancelamento barato e estrutural (solte o future, sua implementação Drop é executada, recursos são liberados), mas também significa que a segurança de cancelamento, se uma operação parcialmente concluída deixa os dados em um estado consistente, é algo que o autor do future tem que projetar explicitamente em vez de ser garantido automaticamente pelo runtime.

Equívocos Comuns

• "Chamar uma função async inicia o trabalho imediatamente." Ela constrói um valor Future preguiçoso e não faz mais nada; o trabalho começa apenas quando algo a chama (polls), tipicamente aguardando-a (awaiting) ou spawnando-a em um executor.
• "A biblioteca padrão do Rust inclui um runtime async." Ela define o trait Future e o contrato de polling, mas não envia nenhum executor; todo programa async real depende de um crate de runtime como Tokio.
• "Pin significa a mesma coisa que imutável." Pin apenas impede que o endereço de memória de um valor mude; o valor ainda pode ser mutado no local através de Pin::as_mut ou métodos seguros que não o movem.
• "Você sempre precisa pensar sobre Pin ao escrever código async." .await faz o pinning de futures na pilha automaticamente para você; Pin geralmente só aparece ao implementar Future manualmente ou ao armazenar um future dentro de outra struct.
• "async/await é um recurso especial de runtime, não código 'real'." É um açúcar sintático comum sobre uma máquina de estados implementando um trait comum; não há mágica oculta de runtime além do próprio protocolo poll/Waker.
• "Soltar (dropping) um future o cancela da mesma forma que matar uma thread." Soltar simplesmente para de chamar (polling) e executa Drop; não há sinal de interrupção, então quaisquer efeitos colaterais parciais já realizados antes do ponto de soltura não são automaticamente desfeitos.

FAQs

Relacionados

• O Trait Future - o contrato poll em detalhes completos, com um exemplo de Future escrito manualmente.
• Executors & Runtimes - o que impulsiona o polling, e como os sabores do Tokio diferem.
• Pinning & Unpin - a API Pin e futures auto-referenciais em profundidade.
• Noções Básicas de Async - exemplos práticos de async/await baseados neste modelo.
• Streams - o equivalente async de um iterador, construído sobre o mesmo modelo de polling.

Versões da Pilha: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.