Асинхронность async/await — бесплатный тест онлайн

Вопрос 1 из 30

Какой способ исправления не расширяет область `unsafe`?

async fn handle() -> std::io::Result<Vec<u8>> {
    let bytes = std::fs::read("large.bin")?;
    Ok(bytes)
}

Закрепить значение рядом с `handle` через небезопасный `Pin::new_unchecked`, не доказывая, что дальнейшие методы не перемещают данные этого фрагмента. Удерживать синхронный guard или другую блокировку через `handle`, полагаясь на короткое время ожидания. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Вынести блокирующую операцию в выделенный blocking pool или использовать асинхронный файловый API runtime; ограничить число одновременных тяжёлых задач. Вызвать блокирующий `block_on` или синхронное ожидание внутри исполнителя рядом с `handle`. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. `spawn` каждую мелкую операцию отдельно и не хранить JoinHandle или протокол отмены. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 2 из 30

Что ещё нужно проверить, прежде чем считать реализацию «Исполнитель асинхронных задач» надёжной?

Локальная Future с заимствованием пригодна для любого spawn после добавления move. Поэтому ошибочный сценарий вокруг «Исполнитель асинхронных задач» не проверяли бы отдельно. Постоянный повторный poll Pending без ожидания пробуждения приводит к активному циклу; корректный Future регистрирует Waker и просит опросить себя после изменения состояния. CPU-bound цикл без await не влияет на соседние задачи executor. Следовательно, для «Исполнитель асинхронных задач» не понадобилось бы явное предусловие. Pin-инвариант важен только до первого poll, а затем Future можно перемещать. Проверку ошибки для «Исполнитель асинхронных задач» при таком подходе заменили бы успешным примером. `spawn` большого числа задач не требует ограничения, поскольку Future ленивы. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение.

Вопрос 3 из 30

Какой случай чаще всего обнаруживает скрытую ошибку в реализации «Будущие вычисления Future»?

Pin-инвариант важен только до первого poll, а затем Future можно перемещать. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. `spawn` большого числа задач не требует ограничения, поскольку Future ленивы. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Тогда поведение «Будущие вычисления Future» при раннем выходе выводили бы из обычного пути. Future может захватывать ресурсы уже при создании внешним выражением, но код внутри async-блока остаётся ленивым до первого poll; эту границу важно различать. Локальная Future с заимствованием пригодна для любого spawn после добавления move. Успешное завершение задачи подтверждает корректность отмены в каждой точке await. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются.

Вопрос 4 из 30

Какое ограничение языка определяет поведение «Тестирование и инструменты Cargo»?

Async-тест должен проверять завершение, отмену, тайм-аут, пробуждение и отсутствие потерянных задач; обычный happy path редко обнаруживает ошибку планирования. Тело async fn начинает выполняться в момент создания Future. Следовательно, поведение `future_is_lazy` считалось бы одинаковым для всех допустимых типов. Move делает каждую захваченную ссылку owned и автоматически даёт Future время жизни static. Контракт «Тестирование и инструменты Cargo» считался бы одинаковым при любом состоянии входа. Move превращает заимствованные данные внутри Future в owned и static. Тогда различия между обычным и граничным случаем для «Тестирование и инструменты Cargo» исчезли бы. Drop незавершённой Future гарантированно выполняет строки после ближайшего await. Проверку ошибки для «Тестирование и инструменты Cargo» при таком подходе заменили бы успешным примером.

Вопрос 5 из 30

Как убрать скрытое предусловие вокруг `std::io::Error`, сохранив исходный замысел?

async fn load() -> Result<String, std::io::Error> {
    let bytes = read_async().await?;
    Ok(String::from_utf8_lossy(&bytes).into_owned())
}

Удерживать std::sync::MutexGuard через await, чтобы состояние не изменилось между этапами. Интерфейс получает совместное владение или синхронизацию даже там, где исходная задача их не требовала. Удерживать синхронный guard или другую блокировку через `load`, полагаясь на короткое время ожидания. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Вызвать блокирующий `block_on` или синхронное ожидание внутри исполнителя рядом с `load`. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Закрепить значение рядом с `load` через небезопасный `Pin::new_unchecked`, не доказывая, что дальнейшие методы не перемещают данные этого фрагмента. Размещать await там, где состояние может безопасно пережить приостановку; не удерживать обычный MutexGuard или заимствование, которое запрещает нужную конкурентность.

Вопрос 6 из 30

Как убрать скрытое предусловие вокруг `std::future::Future`, сохранив исходный замысел?

use std::future::Future;
fn submit<F>(future: F)
where F: Future<Output = ()> + Send + 'static
{
    // runtime.spawn(future)
}

Опросить Future вручную в плотном цикле до Ready, игнорируя Waker. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Выражать требования конкретного executor в границе spawn; для локального исполнителя может быть допустим!Send Future, а scoped API способен ослабить static. Удерживать синхронный guard или другую блокировку через `std::future::Future`, полагаясь на короткое время ожидания. Вызвать блокирующий `block_on` или синхронное ожидание внутри исполнителя рядом с `std::future::Future`. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Закрепить значение рядом с `std::future::Future` через небезопасный `Pin::new_unchecked`, не доказывая, что дальнейшие методы не перемещают данные этого фрагмента.

Вопрос 7 из 30

Какая реализация выражает механизм «Конкурентное выполнение» без лишнего копирования?

async fn sequential() {
    let a = fetch_a().await;
    let b = fetch_b().await;
    use_both(a, b);
}

Удерживать синхронный guard или другую блокировку через `sequential`, полагаясь на короткое время ожидания. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Закрепить значение рядом с `sequential` через небезопасный `Pin::new_unchecked`, не доказывая, что дальнейшие методы не перемещают данные этого фрагмента. Вызвать блокирующий `block_on` или синхронное ожидание внутри исполнителя рядом с `sequential`. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Если операции независимы, создать обе Future и опрашивать совместно через join-подобный комбинатор; spawn использовать только при необходимости отдельной задачи. Вызвать block_on внутри уже работающего однопоточного executor для каждой вложенной Future. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 8 из 30

Какое утверждение о «Безопасность и производительность» остаётся верным при смене входных данных?

Await блокирует поток ОС до получения результата. В результате «Безопасность и производительность» считали бы безопасным и на путях, которых пример не выполняет. Каждый Future создаёт отдельный системный поток. Следовательно, поведение `std::io::Result` считалось бы одинаковым для всех допустимых типов. Await блокирует поток executor до готовности операции. Тогда различия между обычным и граничным случаем для «Безопасность и производительность» исчезли бы. Тело async fn начинает выполняться в момент создания Future. Из этого следовало бы, что иной порядок операций для «Безопасность и производительность» ничего не меняет. Async устраняет ожидание потока только для операций, интегрированных с executor; обычный блокирующий вызов остаётся блокирующим.

Вопрос 9 из 30

Какой случай чаще всего обнаруживает скрытую ошибку в реализации «Приостановка через await»?

Отмена часто происходит простым Drop Future; код после await и обычные действия завершения могут не выполниться, поэтому критические ресурсы должны освобождаться через Drop или явный guard. CPU-bound цикл без await не влияет на соседние задачи executor. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Синхронный MutexGuard через await влияет только на скорость и не способен заблокировать executor. Проверку ошибки для «Приостановка через await» при таком подходе заменили бы успешным примером. Pin-инвариант важен только до первого poll, а затем Future можно перемещать. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Такое рассуждение переносило бы вывод о «Приостановка через await» на неисполненную ветвь. Успешное завершение задачи подтверждает корректность отмены в каждой точке await. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Контракт «Приостановка через await» считался бы одинаковым при любом состоянии входа.

Вопрос 10 из 30

Что выбрать вместо лишнего `clone`, `unwrap` или расширения `unsafe`?

#[test]
fn future_is_lazy() {
    let started = std::sync::Arc::new(std::sync::atomic::AtomicBool::new(false));
    let flag = started.clone();
    let future = async move { flag.store(true, std::sync::atomic::Ordering::SeqCst); };
    assert!(!started.load(std::sync::atomic::Ordering::SeqCst));
    drop(future);
    assert!(!started.load(std::sync::atomic::Ordering::SeqCst));
}

Вызвать block_on внутри уже работающего однопоточного executor для каждой вложенной Future. Разделять тесты чистой state machine и интеграцию с runtime; время моделировать управляемыми часами, а не длинными sleep. Вызвать блокирующий `block_on` или синхронное ожидание внутри исполнителя рядом с `future_is_lazy`. Удерживать синхронный guard или другую блокировку через `future_is_lazy`, полагаясь на короткое время ожидания. Закрепить значение рядом с `future_is_lazy` через небезопасный `Pin::new_unchecked`, не доказывая, что дальнейшие методы не перемещают данные этого фрагмента.

Вопрос 11 из 30

Что станет с данными после ключевой операции?

async fn compute() -> i32 {
    println!("started");
    42
}
let future = compute();
println!("created");
drop(future);

Код компилируется, но drop Future выполняет весь оставшийся код после незавершённого await. Фрагмент печатает только created: вызов async fn создаёт Future, а тело не начинает выполняться без опроса исполнителем. Проверка типов пропустит этот путь: каждый Future создаёт отдельный системный поток. Компиляция закончится диагностикой: future хранится в локальной переменной до опроса. Код считается допустимым, потому что вызов async fn немедленно выполняет тело до первой точки await.

Вопрос 12 из 30

На какую часть контракта распространяется проверка `std::io::Result`?

async fn handle() -> std::io::Result<Vec<u8>> {
    let bytes = std::fs::read("large.bin")?;
    Ok(bytes)
}

# Метрики: executor queue latency растёт, CPU низок, один worker застрял в read().

Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Проверка подтверждает производительность решения, даже если в ней нет измерения времени, памяти или аллокаций; результат проверки с `handle` предлагается переносить на все остальные ветви. Совокупность признаков указывает на блокирующий системный вызов внутри executor; увеличение числа задач усилит, а не исправит задержку. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `std::io::Result` при таком толковании уже не требуется.

Вопрос 13 из 30

Что устанавливает сценарий `future_is_lazy` и где проходит граница его вывода?

#[test]
fn future_is_lazy() {
    let started = std::sync::Arc::new(std::sync::atomic::AtomicBool::new(false));
    let flag = started.clone();
    let future = async move { flag.store(true, std::sync::atomic::Ordering::SeqCst); };
    assert!(!started.load(std::sync::atomic::Ordering::SeqCst));
    drop(future);
    assert!(!started.load(std::sync::atomic::Ordering::SeqCst));
}

# cargo test future_is_lazy -- --exact
# runtime-specific: pause time, spawn task, advance clock, assert state

Первый сценарий независим от executor, второй должен использовать средства выбранного runtime для виртуального времени и контролируемого планирования. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Если основной путь стабилен, ранний выход и повторный вход можно не воспроизводить отдельно. По этой логике отдельная проверка `future_is_lazy` на другом входе считалась бы лишней. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Раз тест прошёл, производительность решения тоже можно считать подтверждённой.

Вопрос 14 из 30

Что именно подтверждает проверка с `future_is_lazy`?

#[test]
fn future_is_lazy() {
    let started = std::sync::Arc::new(std::sync::atomic::AtomicBool::new(false));
    let flag = started.clone();
    let future = async move { flag.store(true, std::sync::atomic::Ordering::SeqCst); };
    assert!(!started.load(std::sync::atomic::Ordering::SeqCst));
    drop(future);
    assert!(!started.load(std::sync::atomic::Ordering::SeqCst));
}

Тест без runtime надёжно подтверждает немедленность: создание и Drop неполученной Future не выполняют тело async-блока. До выполнения код дойдёт без ошибки компиляции, поскольку move превращает заимствованные данные внутри Future в owned и static. Код компилируется, но drop Future выполняет весь оставшийся код после незавершённого await. Проверку ошибки для `future_is_lazy` при таком подходе заменили бы успешным примером. Код компилируется, но pending заставляет executor непрерывно опрашивать Future без wake. Тест без runtime надёжно подтверждает ленивость: создание и Drop неполученной Future не выполняют тело async-блока.

Вопрос 15 из 30

Как следует интерпретировать результат проверки `std::future::Future`?

use std::future::Future;
fn submit<F>(future: F)
where F: Future<Output = ()> + Send + 'static
{
    // runtime.spawn(future)
}

# В трассировке executor: poll -> Pending, затем тысячи poll без wake.

Такая трассировка указывает на ошибочный планировщик или Future, создающий busy loop; нормальный Pending должен ждать сигнала wake. Одного успешного примера достаточно, чтобы считать проверенными и невыполненные ветви контракта. Поэтому ошибочный сценарий вокруг `submit` не проверяли бы отдельно. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 16 из 30

Какой риск остаётся после успешной компиляции кода по теме «Безопасность и производительность»?

CPU-bound цикл без await не влияет на соседние задачи executor. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Spawn большого числа Future без backpressure может исчерпать память, сокеты или лимиты сервиса даже при неблокирующем вводе-выводе. Синхронный MutexGuard через await влияет только на скорость и не способен заблокировать executor. Spawn большого числа задач не требует ограничения, поскольку Future ленивы. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Локальная Future с заимствованием пригодна для любого spawn после добавления move. Тогда различия между обычным и граничным случаем для «Безопасность и производительность» исчезли бы.

Вопрос 17 из 30

Какое решение сохраняет поведение и устраняет источник диагностики?

async fn compute() -> i32 {
    println!("started");
    42
}
let future = compute();
println!("created");
drop(future);

Вызвать блокирующий `block_on` или синхронное ожидание внутри исполнителя рядом с `compute`. Вызвать block_on внутри уже работающего однопоточного executor для каждой вложенной Future. В результате `compute` считали бы безопасным и на путях, которых пример не выполняет. Передать Future исполнителю через await, spawn или block_on подходящего runtime; не считать создание Future запуском операции. Закрепить значение рядом с `compute` через небезопасный `Pin::new_unchecked`, не доказывая, что дальнейшие методы не перемещают данные этого фрагмента. Удерживать синхронный guard или другую блокировку через `compute`, полагаясь на короткое время ожидания.

Вопрос 18 из 30

Как правильно прочитать результат диагностического сценария `.await`?

async fn task() {
    let _guard = Cleanup;
    pending::<()>().await;
}
// drop(task_future) вызовет Drop полей, включая Cleanup.

Нормальный результат на одном входе позволяет распространить тот же вывод на отмену и частичное выполнение. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Проверку ошибки для `task` при таком подходе заменили бы успешным примером. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Отмена уничтожением Future освобождает сохранённые поля, но не выполняет строки после незавершённого await.

Вопрос 19 из 30

Какое правило связывает типы и наблюдаемое поведение в механизме «Приостановка через await»?

Вызов async fn немедленно выполняет тело до первой точки await. Такое рассуждение переносило бы вывод о «Приостановка через await» на неисполненную ветвь. await опрашивает Future и может вернуть управление executor при Pending; локальные значения сохраняются в состоянии внешнего Future между точками приостановки. Drop незавершённой Future гарантированно выполняет строки после ближайшего await. Проверку ошибки для «Приостановка через await» при таком подходе заменили бы успешным примером. Тело async fn начинает выполняться в момент создания Future. Такое рассуждение переносило бы вывод о «Приостановка через await» на неисполненную ветвь. Await блокирует поток executor до готовности операции. Тогда различия между обычным и граничным случаем для «Приостановка через await» исчезли бы.

Вопрос 20 из 30

Как лучше всего описать гарантию механизма «Конкурентное выполнение»?

Drop незавершённой Future гарантированно выполняет строки после ближайшего await. Следовательно, поведение `.await` считалось бы одинаковым для всех допустимых типов. Тело async fn начинает выполняться в момент создания Future. Поэтому ошибочный сценарий вокруг «Конкурентное выполнение» не проверяли бы отдельно. Два последовательных await выполняют операции конкурентно по определению. Тогда поведение «Конкурентное выполнение» при раннем выходе выводили бы из обычного пути. Два последовательных await не означают конкурентность; конкурентный комбинатор должен продвигать обе незавершённые Future. Await блокирует поток executor до готовности операции. Следовательно, для «Конкурентное выполнение» не понадобилось бы явное предусловие.

Вопрос 21 из 30

Какое свойство закрепляет сценарий `.await`?

let a = fetch_a();
let b = fetch_b();
let (ra, rb) = join(a, b).await;

Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Дополнительный сценарий вокруг `.await` при таком толковании уже не требуется. Join-подобная операция опрашивает обе Future и завершится после обеих; она сохраняет структурную отмену внутри родительской задачи. Если обычный путь проходит, поведение при отмене и повторном входе можно считать следствием того же теста. Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Дополнительный сценарий вокруг `.await` при таком толковании уже не требуется.

Вопрос 22 из 30

Что произойдёт после операции `std::future::Future`?

use std::future::Future;
fn submit<F>(future: F)
where F: Future<Output = ()> + Send + 'static
{
    // runtime.spawn(future)
}

Сборка пройдёт, поскольку await блокирует поток executor до готовности операции. Код компилируется, но pending заставляет executor непрерывно опрашивать Future без wake. Значит, выполнение должно пройти через `std::future::Future` без изменения сигнатуры. Сигнатура подходит для многопоточного исполнителя, который хранит задачу независимо: Future и захваты должны быть Send и static. До запуска дело не дойдёт: executor требует Send для многопоточного spawn. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Сигнатура подходит для многопоточного исполнителя, который хранит задачу независимо: Future и захваты должны быть Sync и static.

Вопрос 23 из 30

Как лучше всего описать гарантию механизма «Будущие вычисления Future»?

Каждый Future создаёт отдельный системный поток. Следовательно, поведение `compute` считалось бы одинаковым для всех допустимых типов. Тело async fn начинает выполняться в момент создания Future. Поэтому ошибочный сценарий вокруг «Будущие вычисления Future» не проверяли бы отдельно. Future описывает отложенное вычисление и продвигается только когда его poll вызывают с Context; создание обычно не выполняет тело async fn. Вызов async fn немедленно выполняет тело до первой точки await. Следовательно, поведение `compute` считалось бы одинаковым для всех допустимых типов. Drop незавершённой Future гарантированно выполняет строки после ближайшего await.

Вопрос 24 из 30

Что важно понимать о механизме «Исполнитель асинхронных задач», прежде чем менять код?

Каждый Future создаёт отдельный системный поток. Следовательно, поведение `std::future::Future` считалось бы одинаковым для всех допустимых типов. Pending требует немедленного повторного poll без ожидания wake. Await блокирует поток executor до готовности операции. Тогда поведение «Исполнитель асинхронных задач» при раннем выходе выводили бы из обычного пути. Executor планирует задачи, вызывает poll и использует Waker для повторного опроса после готовности ресурса; сам Future не создаёт поток автоматически. Move делает каждую захваченную ссылку owned и автоматически даёт Future время жизни static. Тогда различия между обычным и граничным случаем для «Исполнитель асинхронных задач» исчезли бы.

Вопрос 25 из 30

Какой итог даст обычный путь выполнения этого кода?

async fn load() -> Result<String, std::io::Error> {
    let bytes = read_async().await?;
    Ok(String::from_utf8_lossy(&bytes).into_owned())
}

Код считается допустимым, потому что await блокирует поток executor до готовности операции. Код компилируется, но drop Future выполняет весь оставшийся код после незавершённого await. Проверку ошибки для `load` при таком подходе заменили бы успешным примером. Сборка пройдёт, поскольку вызов async fn немедленно выполняет тело до первой точки await. Код компилируется, но pending заставляет executor непрерывно опрашивать Future без wake. await приостанавливает текущую async-задачу до готовности read_async, а? после возобновления возвращает ошибку из load.

Вопрос 26 из 30

Какой риск остаётся после успешной компиляции кода по теме «Тестирование и инструменты Cargo»?

Успешное завершение задачи подтверждает корректность отмены в каждой точке await. Spawn большого числа задач не требует ограничения, поскольку Future ленивы. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Можно не проверять потерянное пробуждение, если обычный тайм-аут достаточно велик. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Тест, зависящий от реального времени и порядка потоков, может быть нестабилен; pause/advance часов и каналы делают причинный порядок явным. Локальная Future с заимствованием пригодна для любого spawn после добавления move. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение.

Вопрос 27 из 30

Какое изменение окружения может повлиять на вывод о «Конкурентное выполнение»?

Синхронный MutexGuard через await влияет только на скорость и не способен заблокировать executor. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. CPU-bound цикл без await не влияет на соседние задачи executor. Из этого следовало бы, что иной порядок операций для «Конкурентное выполнение» ничего не меняет. Локальная Future с заимствованием пригодна для любого spawn после добавления move. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Конкурентность не гарантирует параллельность: один executor-thread чередует задачи, а CPU-bound код без yield способен блокировать всех соседей. Spawn большого числа задач не требует ограничения, поскольку Future ленивы. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. По этой логике отдельная проверка «Конкурентное выполнение» на другом входе считалась бы лишней.

Вопрос 28 из 30

Что именно подтверждает проверка с `std::mem::size_of_val`?

async fn value() -> i32 { 7 }
let f = value();
assert_eq!(std::mem::size_of_val(&f) > 0, true);

Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Такой вывод превращает один успешный сценарий в доказательство всего публичного контракта. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Соседние ветви ошибки, отмены и частичного выполнения тогда считают проверенными автоматически. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Измерение показывает размер конкретного объекта Future в этой сборке, но не подтверждает, что его тело было опрошено или что результат уже готов; после drop вычисление так и не запускается.

Вопрос 29 из 30

Каков конечный результат операции `std::io::Result`?

async fn handle() -> std::io::Result<Vec<u8>> {
    let bytes = std::fs::read("large.bin")?;
    Ok(bytes)
}

Проверка типов пропустит этот путь: await блокирует поток executor до готовности операции. Безопасность памяти не нарушена, но синхронный файловый вызов блокирует поток executor и способен остановить множество несвязанных async-задач. Код компилируется, но синхронный файловый вызов автоматически передаёт управление другим задачам. Значит, выполнение должно пройти через `std::io::Result` без изменения сигнатуры. Сборка пройдёт, поскольку каждый Future создаёт отдельный системный поток. Код компилируется, но pending заставляет executor непрерывно опрашивать Future без wake. Значит, выполнение должно пройти через `std::io::Result` без изменения сигнатуры.

Вопрос 30 из 30

Что можно наблюдать после успешной компиляции этого кода?

async fn sequential() {
    let a = fetch_a().await;
    let b = fetch_b().await;
    use_both(a, b);
}

Операции выполняются последовательно: fetch_b даже не создаётся и не опрашивается до завершения fetch_a. Код компилируется, но drop Future выполняет весь оставшийся код после незавершённого await. Тогда различия между обычным и граничным случаем для `sequential` исчезли бы. Код считается допустимым, потому что await блокирует поток executor до готовности операции. Из этого следовало бы, что иной порядок операций для `sequential` ничего не меняет. Код компилируется, но pending заставляет executor непрерывно опрашивать Future без wake. Следовательно, для `sequential` не понадобилось бы явное предусловие. Код не пройдёт проверку: await используется внутри async-функции.