Что меняет пользовательский исполнитель actor в гарантиях его изоляции?
Пользовательский исполнитель (custom executor) меняет способ планирования изолированных участков actor, но не отменяет саму гарантию изоляции. При корректной реализации сериализованного исполнителя доступ к состоянию actor по-прежнему выполняется последовательно; исполнитель лишь определяет, где и каким образом эти работы ставятся на выполнение.
Он не делает безопасными обращения к состоянию actor в обход его изоляции и не превращает произвольный многопоточный исполнитель в безопасный без дополнительных гарантий.
Стандартный планировщик Swift Concurrency обычно сам выбирает исполнителя для продолжений задач. Этого недостаточно, когда actor должен быть интегрирован с существующим циклом событий, специализированной очередью или внешним планировщиком.
Пользовательские исполнители появились как механизм настройки планирования без отказа от модели actor isolation. Это отделяет две задачи: защиту состояния от конкурентного доступа и выбор инфраструктуры, на которой выполняются изолированные работы.
Предположим, состояние actor должно обрабатываться в одном специализированном event loop. Простая передача работы в этот loop может нарушить модель Swift, если не обеспечены требования сериализованного исполнения и корректного взаимодействия с runtime.
Обратная ошибка тоже опасна: можно принять пользовательский исполнитель за механизм блокировки. Тогда разработчик будет считать состояние защищённым, хотя часть доступа выполняется из nonisolated-кода или через внешнюю ссылку без соблюдения изоляции.
У actor есть исполнитель, принимающий готовые единицы работы runtime. При вызове изолированного метода задача не получает прямой одновременный доступ к состоянию: её работа ставится на исполнитель actor и выполняется в соответствии с его правилами.
Пользовательский исполнитель изменяет прежде всего планирование: очередь, event loop, стратегию пробуждения и выбор потока может контролировать интеграционный код. Однако исполнитель actor должен сохранять свойства serial executor: изолированные работы одного actor не должны выполняться одновременно.
После await задача может уступить управление. При возобновлении она снова должна попасть на подходящий исполнитель actor, поэтому нельзя делать вывод, что весь метод непрерывно выполняется на одном потоке или что пользовательский исполнитель запрещает приостановки.
Гарантия относится только к изолированному состоянию данного actor. Если объект, хранящийся в actor, возвращён наружу, вызывающий код не получает автоматической защиты его внутреннего изменяемого состояния. Аналогично, внешний код, который напрямую обращается к общей памяти, не становится безопасным только потому, что рядом существует actor с пользовательским исполнителем.
Главный компромисс — дополнительная сложность. Ошибка в реализации enqueue, нарушение требований сериализации или неправильное смешивание блокирующего и неблокирующего планирования может привести к зависаниям, голоданию задач или неопределённому поведению. Поэтому custom executor оправдан, когда действительно нужна интеграция с конкретным планировщиком, а не просто ради попытки ускорить actor.
Сервис сообщений должен обрабатывать входящие события в уже существующем однопоточном event loop. Вариант со стандартным actor проще и безопаснее: runtime сам планирует работу, но приходится адаптировать обмен с event loop и учитывать дополнительные переходы между исполнителями.
Вариант с обычной очередью и ручными блокировками может сохранить привязку к event loop, однако разработчик сам отвечает за взаимное исключение, порядок операций, повторный вход и корректное ожидание. Это увеличивает вероятность логических гонок и блокировок.
Выбран custom executor actor, интегрированный с event loop. Он принимает работы actor и сериализует их в рамках этого loop, а состояние сервиса остаётся защищённым моделью actor isolation. В результате сохранена интеграция с существующей инфраструктурой без ручного дублирования протокола защиты данных; цена решения — необходимость тщательно протестировать исполнитель и его взаимодействие с runtime.
Нет, это не следует из самого факта пользовательского исполнителя. Он может планировать работу на определённом event loop, но конкретная реализация и её контракт должны явно обеспечивать нужную привязку; actor isolation сама по себе гарантирует сериализацию изолированных работ, а не идентичность потока.
Нет. Исполнитель actor должен обеспечивать сериализованное выполнение принятых работ. Если реализация допускает одновременное выполнение изолированных участков одного actor, она нарушает фундаментальное требование модели и может привести к гонкам данных.
Нет. Исполнитель сериализует работу actor, но не последующие действия вызывающего кода с возвращённым ссылочным объектом. Для безопасности такой объект должен иметь собственный механизм синхронизации, быть неизменяемым или оставаться под контролем изоляции actor.