Какое свойство обязан сохранять пользовательский исполнитель actor, чтобы его изоляция оставалась корректной?
Пользовательский исполнитель actor обязан обеспечивать сериализованное выполнение переданных ему задач: в каждый момент времени его изолированный код не должен выполняться конкурентно на нескольких потоках. Он не обязан сохранять один и тот же поток выполнения, порядок поступления задач или конкретный способ планирования.
Обычный actor передаёт свою работу стандартному планировщику Swift Concurrency. Пользовательские исполнители появились для случаев, когда actor должен интегрироваться со специальной очередью, циклом событий или аппаратно ограниченным контекстом выполнения.
Такой контроль не отменяет модель изоляции actor. Он лишь меняет механизм доставки задач; ответственность за сохранение необходимых гарантий ложится на реализацию исполнителя.
Если пользовательский исполнитель начнёт одновременно выполнять два изолированных фрагмента одного actor, его состояние снова станет доступно из нескольких конкурентных контекстов. Это создаст гонку данных, несмотря на объявление типа как actor и отсутствие диагностик в месте обращения к его состоянию.
Обратная ошибка тоже возможна: исполнитель может выполнять задачи строго последовательно, но блокировать поток длительными операциями. Тогда гонок не будет, однако возрастут задержки и уменьшится пропускная способность приложения.
Исполнитель actor должен соответствовать семантике serial executor: он принимает задания, представляющие продолжения изолированных операций, и не допускает их одновременного выполнения в рамках данного actor. После await actor может принять другую задачу, поэтому сериализация означает отсутствие одновременного выполнения, а не сохранение непрерывного владения исполнением.
Исполнитель может менять поток между двумя заданиями. Изоляция обеспечивается не привязкой к потоку, а тем, что критические участки actor проходят через один сериализованный исполнитель.
Этот контракт не гарантирует FIFO-порядок, справедливость, отсутствие голодания или автоматическую защиту объектов, которыми actor поделился наружу. Также исполнитель не превращает синхронную блокирующую работу в асинхронную: длительная операция внутри его задания всё равно может задержать другие изолированные операции.
На практике пользовательский исполнитель должен корректно ставить задания в очередь, запускать каждое задание в поддерживаемом контексте и не допускать рекурсивного или конкурентного обхода контракта сериализации. Если эти гарантии нельзя доказать, безопаснее использовать стандартный исполнитель actor.
Сервис actor работает поверх собственного цикла событий библиотеки, и команда хочет выполнять его обработчики в этом цикле. Вариант со стандартным executor проще и надёжнее, но требует явного взаимодействия с библиотекой и может привести к дополнительным переключениям контекста. Вариант с пользовательским executor уменьшает такие переключения, но требует доказать сериализацию, корректное завершение очереди и отсутствие блокировок.
Выбран пользовательский executor, который принимает задания в одну очередь цикла событий и запускает их последовательно. Долгие операции вынесены за пределы этого цикла или выполняются через отдельные задачи, поэтому изоляция actor сохранена без остановки прогресса остальных операций.
Нет. Обязательна сериализация, а не постоянство потока. Исполнитель может продолжить следующую часть работы на другом потоке, если ни одна изолированная операция этого actor не выполняется одновременно с другой.
Нет, если это отдельно не предусмотрено его контрактом. Actor защищает от конкурентного выполнения изолированных участков, но порядок их обработки может зависеть от планировщика, приоритетов и реализации очереди.
Нет. Потокобезопасность очереди защищает структуру очереди, но сама по себе не доказывает, что извлечённые задания не будут запущены одновременно. Нужно отдельно обеспечить единственного активного исполнителя задания и корректно синхронизировать переходы между состояниями очереди.