Segurança contra cancelamento em diferentes runtimes assíncronos do Rust

2026-04-01T00:00:00+00:00

Para obter mais contexto, recomendo aos meus amigos que leiam ou assistam a ótima palestra</a> feita pela Rain, onde ela descreveu sua postura em relação à “segurança contra cancelamento” no Rust assíncrono.</p>

TL;DR para aqueles que preferem codar e não ler:</p>

git clone https://gitlab.com/blogging1/cancellation-safety</code>;</li>

cargo test --no-fail-fast --workspace</code> (ou seu runtime de escolha usando -p cancel_%RUNTIME%</code> em vez de --workspace</code>);</li>

Leia os erros e os testes;</li>

Leia lib.rs</code> para os runtimes em que você está interessado;</li>

Jogue com o código para corrigir todos os testes;</li>
</ul>

</i></a>
O Problema</h1>
“Segurança contra cancelamento” geralmente significa ausência de efeitos inesperados quando uma sequência de operações assíncronas é interrompida
antes de atingir o estado final.
Posso pensar em um panic!</code> no meio de uma sequência síncrona de operações como uma analogia.</p>
Os princípios fundamentais estão ligados ao trait Future</code> e aos detalhes de implementação do Runtime Assíncrono.
Aqui, quero experimentar na tentativa de encontrar padrões comuns e diferenças em como Tokio, smol e glommio lidam com cancelamentos.</p>

Future::poll</code> é um aspecto chave aqui, pois em tempo de compilação cada implementação de Future</code> é uma máquina de estados, que representa uma sequência de operações,
“cancelamento” significa que o Runtime</strong> (Reator, Loop de Eventos ou Escalonador) para de sondar esta máquina de estados e (espera-se) destrói seu estado;</li>
Pin</code> e Unpin</code> têm seus próprios lugares, pois tipos !Unpin</code> precisam manter garantias adicionais para serem considerados “seguros” (mitigar “efeitos”);</li>
A implementação de Waker</code> pode desempenhar um grande papel no tratamento de solicitações de “cancelamento”;</li>
</ul>
</i></a>
O Exemplo</h1>
Em nossa aventura, vamos nos juntar aos nossos fortes e orgulhosos amigos que vivem em Moria:</p>
pub</span> async</span> fn</span> mine_with_tool</span><</span>F</span>,</span> FT</span>></span>(</span>dwarf</span>:</span> &</span>mut</span> Dwarf</span>,</span> mut</span> pickaxe</span>:</span> F</span>)</span> ...</span> {</span></span>
    let</span> mut</span> bag</span>:</span> Bag</span> =</span> Vec</span>::</span>new</span>(</span>)</span>;</span></span>
    for</span> i</span> in</span> 0</span>..</span>MAX_ALLOWED_SHIFTS</span> {</span></span>
        pickaxe</span>(</span>)</span>.</span>await</span>;</span></span>
        ...</span></span>
        println!</span>(</span>"</span>Aqui nos Portões o rei AGUARDA</span>"</span>)</span>;</span></span>
        ...</span></span>
        bag</span>.</span>push</span>(</span>Ferrum</span>::</span>Dirty</span>)</span>;</span></span>
    }</span></span>
    dwarf</span>.</span>bag </span>=</span> Some</span>(</span>bag</span>)</span>;</span></span>
}</span></span></code></pre>
então nosso processo assíncrono imitará um anão trabalhando nas minas. O mine_with_tool</code> em si é uma implementação composta de trait Future</code>,
que internamente executa MAX_ALLOWED_SHIFTS</code> passos para atingir seu estado final (completo). Em termos simples, linha 4: pickaxe().await;</code>
será um ponto onde a máquina de estados é sondada e faz progresso. Isso significa que esse exato local
pode ser usado para “cancelar” a execução.</p>
Como se vê em uma representação intermediária de alto nível (código limpo para torná-lo menos verboso, por favor execute cargo +nightly rustc -- -Z unpretty=hir</code>
dentro da pasta moria</code> para ver a saída completa):</p>
async</span> fn</span> mine_with_tool</span><</span>F</span>,</span> FT</span>></span>(</span>dwarf</span>:</span> &</span>'</span>_</span> mut</span> Dwarf</span>,</span> pickaxe</span>:</span> F</span>)</span> -></span> /*</span>impl Trait</span>*/</span></span>
    where</span> F</span>:</span> FnMut</span>(</span>)</span> -></span> FT</span>,</span> FT</span>:</span> std</span>::</span>future</span>::</span>Future</span> |</span>mut</span> _task_context</span>:</span> ResumeTy</span>|</span></span>
{</span></span>
    ...</span></span>
    let</span> mut</span> bag</span>:</span> Bag</span> =</span> Vec</span>::</span>new</span>(</span>)</span>;</span></span>
    {</span></span>
        ...</span></span>
        loop</span> {</span></span>
            match</span> next</span>(</span>&</span>mut</span> iter</span>)</span> {</span></span>
                None</span> {</span>}</span> =></span> break</span>,</span></span>
                Some</span> {</span>  0</span>:</span> i</span> }</span> =></span> {</span></span>
                    match</span> into_future</span>(</span>pickaxe</span>(</span>)</span>)</span> {</span></span>
                        mut</span> __awaitee</span> =></span></span>
                            loop</span> {</span></span>
                                match</span> unsafe</span> {</span></span>
                                        poll</span>(</span>new_unchecked</span>(</span>&</span>mut</span> __awaitee</span>)</span>,</span></span>
                                            get_context</span>(</span>_task_context</span>)</span>)</span></span>
                                    }</span> {</span></span>
                                    Ready</span> {</span>  0</span>:</span> result</span> }</span> =></span> break</span> result</span>,</span></span>
                                    Pending</span> {</span>}</span> =></span> {</span> }</span></span>
                                }</span></span>
                                _task_context</span> =</span> (</span>yield</span> (</span>)</span>)</span>;</span></span>
                            }</span>,</span></span>
                    }</span>;</span></span>
                    ...</span></span>
                    bag</span>.</span>push</span>(</span>Ferrum</span>::</span>Dirty</span>)</span>;</span></span>
                }</span></span>
            }</span></span>
        }</span>,</span></span>
        ...</span></span>
    dwarf</span>.</span>bag </span>=</span> Some</span>(</span>bag</span>)</span>;</span></span>
    ...</span></span>
}</span></span></code></pre>
quase não há mais “mágica” assíncrona, temos um loop</code>, um unsafe</code> e um yield ()</code>.</p>
Vamos saltar para o aspecto de “segurança”. Na minha humilde opinião, se não há código unsafe</code> e o compilador Rust está satisfeito, a operação é segura.
No entanto, isso não significa que o programa se comporta da maneira que os programadores podem esperar que ele se comporte.</p>
...</span> fn</span> mine_with_tool</span><</span>...</span>></span>(</span>dwarf</span>:</span> &</span>mut</span> Dwarf</span> ...</span> {</span></span>
    let</span> mut</span> bag</span>:</span> Bag</span> =</span> Vec</span>::</span>new</span>(</span>)</span>;</span></span>
        ...</span></span>
        bag</span>.</span>push</span>(</span>Ferrum</span>::</span>Dirty</span>)</span>;</span></span>
        ...</span></span>
    dwarf</span>.</span>bag </span>=</span> Some</span>(</span>bag</span>)</span>;</span></span>
}</span></span></code></pre>
tente identificar você mesmo o que torna esta implementação de trait Future</code> ser chamada de “não segura contra cancelamento” (eu prefiro não segura aqui, pois unsafe</strong>
é importante mas um termo Rust não relacionado).</p>
A resposta reside em como esta operação assíncrona armazena seu estado e rastreia seu próprio progresso. Ambas as coisas acontecem internamente, enquanto mantém uma referência mutável
ao estado fornecido pelo lado do chamador dwarf: &mut Dwarf</code>. Vamos ver dois exemplos desse uso de recurso dentro do runtime smol</code> para ver por que
tal implementação pode dar surpresas ao chamador se for cancelada.</p>
pub</span> async</span> fn</span> work</span>(</span>dwarf</span>:</span> &</span>mut</span> Dwarf</span>)</span> {</span></span>
    super</span>::</span>mine</span>(</span>dwarf</span>)</span></span>
        .</span>or</span>(</span>async</span> {</span></span>
            Timer</span>::</span>after</span>(</span>HALF_SHIFT</span>)</span>.</span>await</span>;</span></span>
        }</span>)</span></span>
        .</span>await</span>;</span></span>
}</span></span></code></pre>
O Anão trabalha aqui metade do tempo de turno e fez algum progresso.
Mas quando vamos ver executar o teste:</p>
let</span> mut</span> dwallin</span> =</span> Dwarf</span>::</span>new</span>(</span>Name</span>::</span>Dwalin</span>)</span>;</span></span>
timeout</span>::</span>work</span>(</span>&</span>mut</span> dwallin</span>)</span>.</span>await</span>;</span></span>
//</span> A mochila está vazia, mas ouvi a música!</span></span>
assert!</span>(</span>dwallin</span>.</span>bag</span>.</span>is_some</span>(</span>)</span>)</span>;</span></span></code></pre>
vemos que a assertiva de que algum trabalho foi feito falha. A razão é que o timeout aconteceu antes que Dwalin pudesse terminar
seu trabalho e tudo o que ele colocou na “mochila” no estado interno da máquina de estados foi descartado assim que cancelamos a operação
na primeira sondagem após o timeout. (Tente mudar Timer::after(HALF_SHIFT)</code> para usar FULL_SHIFT</code> e veja se isso ajuda 😉).
Então isso é o que podemos dizer uma implementação não segura contra cancelamento (ou incorreta como a Rain propôs) de uma operação assíncrona que leva a
um comportamento que não esperamos.</p>
Mais interessante (e mais próximo do mundo real) pode acontecer se fizermos nossa implementação de Future</code> mais complexa e “suja”:</p>
pub</span> async</span> fn</span> work</span>(</span>dwarf</span>:</span> &</span>Mutex</span><</span>Dwarf</span>></span>)</span> {</span></span>
    let</span> mut</span> dwarf_guard</span> =</span> dwarf</span>.</span>lock</span>(</span>)</span>.</span>await</span>;</span></span>
    let</span> mut</span> old_bag</span> =</span> dwarf_guard</span>.</span>bag</span>.</span>take</span>(</span>)</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    timeout</span>(</span>HALF_SHIFT</span>,</span> super</span>::</span>mine</span>(</span>&</span>mut</span> dwarf_guard</span>)</span>)</span></span>
        .</span>await</span></span>
        .</span>err</span>(</span>)</span></span>
        .</span>unwrap</span>(</span>)</span>;</span></span>
    if</span> let</span> Some</span>(</span>new_bag</span>)</span> =</span> dwarf_guard</span>.</span>bag</span>.</span>as_mut</span>(</span>)</span> {</span></span>
        new_bag</span>.</span>append</span>(</span>&</span>mut</span> old_bag</span>)</span></span>
    }</span></span>
}</span></span></code></pre>
Eu sei, Anões não são bons em programação assíncrona, mas isso ilustra o problema muito bem.
Nossa operação retira o estado do input, o mantém internamente, depois acumula com resultados de computação próprios e o devolve.</p>
┌────────────────────────────────────────────────────────────────────────────────────────────────────┐</span></span>
│  ┌──────────────┐    ┌──────────────────┐    ┌───────────┐    ┌───────────────┐    ┌──────────────┐│</span></span>
│  │ Travar Mutex │ -> │ Tomar Bag Antiga │ -> │ Mineração │ -> │Tomar Nova Bag │ -> │ Mesclar Bags ││</span></span>
│  └──────────────┘    └──────────────────┘    └───────────┘    └───────────────┘    └──────────────┘│</span></span>
│  ┌──────────────┐    ┌──────────────┐                                                              │</span></span>
│->│Liberar Travar│ -> │    Fim       │                                                              │</span></span>
│  └──────────────┘    └──────────────┘                                                              │</span></span>
└────────────────────────────────────────────────────────────────────────────────────────────────────┘</span></span></code></pre>
O problema é que a operação é “segura” do ponto de vista do mutex, pois sabemos que ninguém mais alterará o estado do dwarf</code>.
No entanto, não é “correto” se cancelarmos super::mine</code> antes que ele seja completamente concluído. old_bag</code> será descartado assim como new_bag</code>
não existirá (dwarf_guard.bag.as_mut()</code> é None</code>). Como a implementação de futuro de work</code> é uma composição de si mesmo com
a implementação de futuro de super::mine</code> e a implementação de futuro de timeout</code>, nossa lógica se torna quebrada, pois ambos os futuros
têm comportamento incorreto do ponto de vista do sistema (enquanto isso é totalmente esperado, válido e seguro</strong> código Rust na minha opinião).</p>
</i></a>
A Comparação</h1>
</i></a>
Visão Geral da Arquitetura do Runtime</h2>
</i></a>
Tokio: O Padrão da Indústria</h3>
Tokio representa o runtime assíncrono mais amplamente usado no ecossistema Rust. Sua arquitetura foca em:</p>

Pool de threads multi-thread</strong> para trabalhos ligados à CPU;</li>
Modelo de I/O baseado em completers</strong> para operações não bloqueantes;</li>
Cancelamento robusto de tarefas</strong> com capacidades de aborto explícito;</li>
Ecossistema abrangente</strong> de bibliotecas de suporte;</li>
</ul>
Características principais:</p>

Tokens de cancelamento integrados via tokio_util::sync::CancellationToken</code>;</li>
tokio::spawn()</code> para criar tarefas;</li>
tokio::select!</code> para operações concorrentes;</li>
Utilitários de timeout integrados;</li>
</ul>
</i></a>
smol: A Abordagem Mínima</h3>
smol toma uma abordagem radicalmente diferente com:</p>

Executor mono-thread</strong> por padrão;</li>
API simplificada</strong> focando em operações assíncronas essenciais;</li>
Sem runtime próprio</strong> - ele traz executores existentes;</li>
Dependências leves</strong> e sobrecarga mínima;</li>
</ul>
Características principais:</p>

smol::spawn()</code> para criação de tarefas;</li>
smol::Timer</code> para atrasos assíncronos;</li>
smol::channel</code> para passagem de mensagens;</li>
Sem tokens de cancelamento explícitos na API central;</li>
</ul>
</i></a>
Glommio: Foco em Performance de I/O</h3>
Glommio representa um runtime especializado para cargas de trabalho de I/O de alta performance:</p>

Modelo de executor local</strong> com abordagem de compartimento-zero primeiro;</li>
Otimizado para I/O</strong> com arquitetura thread por núcleo dedicada;</li>
Sem memória compartilhada</strong> entre threads por padrão;</li>
Futuros locais-only</strong> para melhor localidade de cache;</li>
</ul>
Características principais:</p>

glommio::LocalExecutor</code> para execução mono-thread;</li>
glommio::spawn_local()</code> para tarefas;</li>
glommio::timer</code> para atrasos;</li>
glommio::channels::local_channel</code> para comunicação local-only;</li>
</ul>
</i></a>
Análise de Cenários de Cancelamento</h2>
A maioria dos cenários funciona de forma semelhante entre runtimes:</p>

Cancelamento de Drop Simples: Use mecanismos de drop explícitos para futuros e todos os runtimes mostram perda parcial de trabalho quando futuros são dropados inesperadamente;</li>
Cancelamento de Timeout: Todos fornecem tratamento de timeout explícito e os testes mostram que o timeout não preserva resultados parciais;</li>
Operações Protegidas por Mutex: tokio::sync::Mutex</code>, smol::lock::Mutex</code>, glommio::sync::RwLock</code> compartilham semânticas semelhantes,
enquanto os testes demonstram padrões de manutenção de bloqueio e limpeza funciona como deveria, embora ainda percam nosso progresso;</li>
Comunicação Baseada em Canal: muito semelhante, apenas com nuances de localidade;</li>
</ul>
Mas alguns têm nuances:</p>

Macros como select!</code> e Operações Concorrentes com Tokens de Cancelamento são específicos ao ecossistema de runtime Tokio</code>, o que parece não ser algo bom
ou ruim. Como a Rain descreveu em sua palestra e o que ouvi de outros desenvolvedores, esses macros às vezes são totalmente banidos em projetos devido à sua natureza não explícita
(e por exemplo substituídos por futures_concurrency</a>);</li>
“Cancelamento Explícito”:

em Tokio</code> é feito via JoinHandle::abort</code> e o descarte do handle não causará um cancelamento, nahdle.await</code> retornará um erro JoinError</code>
se a implementação de futuro foi cancelada (ou resultado normal se concluiu), também vale notar que tarefas spawn_blocking</code> não são “cancelláveis” pois não são assíncronas
(mas isso impedirá a tarefa de iniciar se ainda não o foi!);</li>
em smol</code> você pode chamar Task::cancel</code> e esperar pelo cancelamento (que pode retornar Some</code> se concluiu), é similar ao descarte da implementação de futuro;</li>
em glommio</code> a abordagem também é idêntica a smol</code> com Option</code> sendo retornado ao aguardar o cancelamento;</li>
</ul>
</li>
</ul>
Do lado da documentação, este tópico é coberto apenas nos docs da API Tokio</code>, smol</code> tem uma pequena nota (he-he) sobre este assunto:Nota que cancelar uma tarefa acorda realmente e agenda uma última vez. Então, o executor pode destruir a tarefa simplesmente descartando seu Runnable ou invocando run().</strong>, enquanto no glommio</code> não consegui encontrar menção sobre segurança contra cancelamento ou correção. Acho que há dois fatores por que é, o que é:</p>

Tokio tem muito mais popularidade e uso, embora tenha mais recursos para adicionar documentação;</li>
Tokio tem muito mais API “perigosa” e modelo de executor interno que torna mais fácil cair em problemas de segurança contra cancelamento usando-o;</li>
</ol>
Espero que você tenha encontrado algo novo neste post de blog, escreva seus pensamentos nos comentários e verifique recursos adicionais se desejar.</p>
</i></a>
Recursos Adicionais e Fontes de Inspiração</h1>

Ótima Palestra da Rain talk</a>;</li>
Comentário atual na seção state of the book</a> sobre segurança contra cancelamento;</li>
Docs do Tokio sobre isso</a></li>
Structured Concurrency lib</a></li>
</ul>

Blog do Bishonen - Rust

Casts Não Tão Triviais

Segurança contra cancelamento em diferentes runtimes assíncronos do Rust

Tipos Rust - Taxonomia

Okxlivro - Post Mortem

Microsserviços em Rust - Estrutura do Projeto

Blog do Bishonen - Rust

Casts Não Tão Triviais

Segurança contra cancelamento em diferentes runtimes assíncronos do Rust

</i></a> smol: A Abordagem Mínima</h3> smol toma uma abordagem radicalmente diferente com:</p> Executor mono-thread</strong> por padrão;</li> API simplificada</strong> focando em operações assíncronas essenciais;</li> Sem runtime próprio</strong> - ele traz executores existentes;</li>

Tipos Rust - Taxonomia

Okxlivro - Post Mortem

Microsserviços em Rust - Estrutura do Projeto