Безопасность отмены в разных Rust Async-рантаймах

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

Для более глубокого понимания я рекомендую своим дорогим друзьям прочитать или посмотреть отличный тред</a>, сделанный Рейном, где она описывает её отношение к “безопасности отмены” в Rust с асинхронностью.</p>

TL;DR для тех, кто предпочитает хакать, а не читать:</p>

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

cargo test --no-fail-fast --workspace</code> (или ваш рантайм по выбору с -p cancel_%RUNTIME%</code> вместо --workspace</code>);</li>

Читайте ошибки и тесты;</li>

Читайте lib.rs</code> для рантаймов, которые вас интересуют;</li>

Играйте с кодом, чтобы исправить все тесты.</li>
</ul>

</i></a>
Проблема</h1>
“Безопасность отмены” обычно означает отсутствие неожиданных “эффектов”, когда последовательность асинхронных операций прерывается до того, как она достигнет финального состояния.
Я могу представить panic!</code> посередине синхронной последовательности операций как аналогию.</p>
Её фундаментальные принципы связаны с трейтом Future</code> и деталями реализации асинхронного рантайма.
Здесь я хотел бы провести эксперимент, чтобы найти общие паттерны и различия в том, как Tokio, smol и glommio обрабатывают отмены.</p>

Future::poll</code> — ключевой аспект здесь, так как на этапе компиляции каждая реализация Future</code> представляет собой конечный автомат,
представляющий последовательность операций, “отмена” означает, что Runtime</strong> (Реактор, Event Loop или планировщик) перестанет опрашивать этот конечный автомат и (надеюсь) уничтожит его состояние;</li>
Pin</code> и Unpin</code> имеют свои места, так как типы !Unpin</code> должны обеспечивать дополнительные гарантии, чтобы считаться “безопасными” (снижение “эффектов”);</li>
Реализация Waker</code> может играть большую роль в обработке запросов об отмене.</li>
</ul>
</i></a>
Пример</h1>
В нашем приключении мы присоединимся к нашим сильным и гордым друзьям, живущим в Мории:</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>Здесь у ворот король ОЖИДАЕТ</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>
так наш асинхронный процесс будет имитировать работу гнома в шахтах. Сам mine_with_tool</code> является композитной реализацией trait Future</code>,
внутри которой выполняется MAX_ALLOWED_SHIFTS</code> шагов для достижения своего финального (завершенного) состояния.
Простыми словами, строка 4: pickaxe().await;</code> будет точкой, где конечный автомат опрашивается и продвигается вперед.
Это означает, что именно в этом месте может быть использовано для “отмены” выполнения.</p>
Как это выглядит на высокоуровневом промежуточном представлении (код очищен для большей лаконичности, пожалуйста, запустите cargo +nightly rustc -- -Z unpretty=hir</code>
внутри папки moria</code>, чтобы увидеть полный вывод):</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>
почти никакой “async” магии больше, у нас есть loop</code>, unsafe</code> и yield ()</code>.</p>
Давайте перейдем к “безопасности”. По моему скромному мнению, если нет unsafe</code> кода и компилятор Rust доволен, операция безопасна.
Однако это не означает, что программа ведет себя так, как ожидают от неё программисты.</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>
попробуйте сами понять, что делает эту реализацию trait Future</code> названной “небезопасной отменой” (я предпочитаю небезопасная, так как unsafe</strong>
важно, но является отдельным термином Rust).</p>
Ответ кроется в том, как эта асинхронная операция хранит свое состояние и отслеживает свой прогресс. Обе эти вещи происходят внутренне,
при этом удерживая изменяемую ссылку на состояние, предоставляемую вызывающей стороной dwarf: &mut Dwarf</code>.
Давайте посмотрим на два примера использования этой функции внутри рантайма smol</code>, чтобы понять, почему такая реализация может давать сюрпризы вызывающей стороне,
если произойдет отмена.</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>
Гном здесь работает половину смены времени и сделал некоторый прогресс.
Но когда мы идем смотреть, как запускается тест:</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> Сумка пуста, но я слышал песню!</span></span>
assert!</span>(</span>dwallin</span>.</span>bag</span>.</span>is_some</span>(</span>)</span>)</span>;</span></span></code></pre>
мы видим, что проверка того, что работа была проделана, не проходит.
Причина в том, что таймаут наступил до того, как Двалину удалось завершить свою работу, и всё, что он положил в “сумку”
во внутреннем состоянии конечного автомата, было отброшено, как только мы отменили операцию в первом опросе после таймаута.
(Попробуйте изменить Timer::after(HALF_SHIFT)</code> на использование FULL_SHIFT</code> и посмотрите, поможет ли это 😉).
Так это то, что мы можем назвать небезопасной отменой (или некорректной, как предложила Рейн) реализацией асинхронной операции,
которая приводит к поведению, которого мы не ожидаем.</p>
Более интересный (и более близкий к реальности) сценарий может произойти, если сделать нашу реализацию Future</code> более сложной и “грязной”:</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>
Я знаю, гномы не любят асинхронное программание, но это иллюстрирует проблему очень хорошо.
Наша операция извлекает состояние из входных данных, держит его внутренне, затем накапливает с собственными результатами вычислений и возвращает его обратно.</p>
┌────────────────────────────────────────────────────────────────────────────────────────┐</span></span>
│  ┌────────────┐    ┌──────────────┐    ┌───────┐    ┌─────────────┐    ┌──────────────┐│</span></span>
│  │ Lock Mutex │ -> │ Take Old Bag │ -> │ Mine  │ -> │Take New Bag │ -> │  Merge Bags  ││</span></span>
│  └────────────┘    └──────────────┘    └───────┘    └─────────────┘    └──────────────┘│</span></span>
│  ┌────────────┐    ┌──────────────┐                                                    │</span></span>
│->│Release Lock│ -> │    End       │                                                    │</span></span>
│  └────────────┘    └──────────────┘                                                    │</span></span>
└────────────────────────────────────────────────────────────────────────────────────────┘</span></span></code></pre>
Проблема в том, что с точки зрения мьютекса операция “безопасна”, так как мы знаем, что никто больше не изменит состояние dwarf</code>.
Однако она “некорректна”, если мы отменим super::mine</code> до того, как она полностью завершится.
old_bag</code> будет отброшен, так как new_bag</code> не будет существовать (dwarf_guard.bag.as_mut()</code> равно None</code>).
Так как реализация будущего work</code> является композицией самой себя с реализацией будущего super::mine</code> и реализацией будущего timeout</code>,
наша логика ломается, так как оба будущего ведут себя некорректно с точки зрения системы (хотя это полностью ожидаемо, валидно и безопасно</strong> Rust-код по моему мнению).</p>
</i></a>
Сравнение</h1>
</i></a>
Обзор архитектуры рантайма</h2>
</i></a>
Tokio: Отраслевой стандарт</h3>
Tokio представляет собой самый широко используемый асинхронный рантайм в экосистеме Rust.
Его архитектура фокусируется на:</p>

Многопоточный пул исполнителей</strong> для вычислительно-тяжелых задач;</li>
Модель завершения на основе Completer</strong> для неблокирующих операций;</li>
Надежная отмена задач</strong> с явными возможностями прерывания;</li>
Комплексная экосистема</strong> поддерживающих библиотек;</li>
</ul>
Ключевые характеристики:</p>

Встроенные токены отмены через tokio_util::sync::CancellationToken</code>;</li>
tokio::spawn()</code> для создания задач;</li>
tokio::select!</code> для одновременных операций;</li>
Встроенные утилиты таймаута;</li>
</ul>
</i></a>
smol: Минималистичный подход</h3>
smol использует радикально другой подход с:</p>

Однопоточный исполнитель</strong> по умолчанию;</li>
Упрощенный API</strong>, фокусирующийся на основных асинхронных операциях;</li>
Собственного рантайма нет</strong> — он предоставляет существующие исполнители;</li>
Легковесные зависимости</strong> и минимальные накладные расходы;</li>
</ul>
Ключевые характеристики:</p>

smol::spawn()</code> для создания задач;</li>
smol::Timer</code> для асинхронных задержек;</li>
smol::channel</code> для передачи сообщений;</li>
Нет явных токенов отмены в основном API;</li>
</ul>
</i></a>
Glommio: Фокус на производительности I/O</h3>
Glommio представляет собой специализированный рантайм, разработанный для высокопроизводительных нагрузок I/O:</p>

Локальная модель исполнителя</strong> с подходом “share-nothing-first”;</li>
Оптимизированный для I/O</strong> с архитектурой thread-per-core;</li>
Нет общей памяти</strong> между потоками по умолчанию;</li>
Локальные только futures</strong> для лучшей локальности кэша;</li>
</ul>
Ключевые характеристики:</p>

glommio::LocalExecutor</code> для однопоточного выполнения;</li>
glommio::spawn_local()</code> для задач;</li>
glommio::timer</code> для задержек;</li>
glommio::channels::local_channel</code> для локальной только коммуникации;</li>
</ul>
</i></a>
Анализ сценариев отмены</h2>
Большинство сценариев ведут себя похоже в разных рантаймах:</p>

Простая отмена через Drop: используйте явные механизмы drop для futures, и все рантаймы показывают частичную потерю работы, когда futures отбрасываются неожиданно;</li>
Отмена через таймаут: все предоставляют явную обработку таймаута, и тесты показывают, что таймаут не сохраняет частичные результаты;</li>
Операции, защищенные мьютексом: tokio::sync::Mutex</code>, smol::lock::Mutex</code>, glommio::sync::RwLock</code> имеют схожую семантику,
в то время как тесты демонстрируют паттерны удержания блокировок и очистка работает так, как должно, хотя мы все равно теряем прогресс;</li>
Коммуникация на основе каналов: очень похоже, только с нюансами локальности;</li>
</ul>
Но некоторые из них имеют нюансы:</p>

Макросы вроде select!</code> и одновременные операции с токенами отмены специфичны для экосистемы рантайма Tokio</code>,
что кажется не хорошим или плохим делом. Как описала Рейн в своём треде и что я слышал от других разработчиков,
такие макросы иногда полностью запрещаются в проектах из-за их неявного характера (и например заменяются на futures_concurrency</a>);</li>
“Явная” отмена:

в Tokio</code> делается через JoinHandle::abort</code>, и отбрасывание хендла не вызывает отмену, nahdle.await</code> вернет ошибку JoinError</code>
если реализация будущего была отменена (или нормальный результат, если она завершилась), также стоит отметить, что задачи spawn_blocking</code> не являются “отменяемыми”,
так как они не асинхронны (но это предотвратит запуск задачи, если она еще не началась!);</li>
в smol</code> можно вызвать Task::cancel</code> и дождаться отмены (которая может вернуть Some</code>, если завершилась), это похоже на отбрасывание реализации будущего;</li>
в glommio</code> подход также идентичен smol</code> с тем, что возвращается Option</code> при ожидании отмены;</li>
</ul>
</li>
</ul>
Со стороны документации эта тема покрыта только в документации API Tokio</code>, smol</code> имеет одну маленькую (ха-ха) заметку на этот счет:Примечание, что отмена задачи на самом деле разбудит её и перепланирует в последний раз. Затем исполнитель может уничтожить задачу, просто отбросив её Runnable или вызвав run().</strong>,
в то время как в glommio</code> я не смог найти упоминаний о безопасности отмены или корректности. Я думаю, есть два фактора, почему это так:</p>

У Tokio гораздо большая популярность и использование, хотя и больше ресурсов для добавления документации;</li>
У Tokio гораздо более “опасный” API и внутренняя модель исполнителя, что делает его легче встретить проблемы безопасности отмены при его использовании;</li>
</ol>
Надеюсь, вы нашли что-то новое в этом блог-посте, пишите свои мысли в комментариях и проверьте дополнительные ресурсы, если хотите.</p>
</i></a>
Дополнительные ресурсы и источники вдохновения</h1>

Отличный тред Рейна talk</a>;</li>
Текущий комментарий о state of the book section</a> о безопасности отмены;</li>
Документация Tokio на эту тему</a></li>
Structured Concurrency lib</a></li>
</ul>
(Конец файла - всего 266 строк)</p>

Блог Бишонена - Concurrency

Безопасность отмены в разных Rust Async-рантаймах