Ответ на вопрос
Модель параллелизма Swift была значительно укреплена в версии 6.0, введя строгие требования к изоляции данных, которые распространяются за пределы модулей. Когда модуль, скомпилированный с строгой проверкой параллелизма, вызывает старый модуль, помеченный @preconcurrency, компилятор не может полагаться только на статический анализ для гарантии безопасности, так как реализация вызываемой функции может предшествовать гарантиям изоляции актора. Для устранения этого разрыва Swift встраивает требования к изоляции в качестве метаданных в информацию о типе функции и таблицы свидетельств, сохраняя стабильность ABI, не изменяя соглашения о вызовах или «мягкие» имена символов. Во время выполнения сгенерированный код выполняет динамическую проверку с использованием встроенной функции swift_task_isCurrentExecutor, чтобы убедиться, что текущая задача выполняется на требуемом последовательном исполнителе глобального актора перед продолжением; если проверка не проходит, задача добавляется асинхронно на правильный исполнитель или вызывается диагностическая ошибка, в зависимости от конфигурации сборки.
Ситуация из жизни
Команда финансовых технологий поддерживала старый аналитический SDK (Модуль B), написанный на Swift 5.9, который выполнял тяжелые статистические вычисления в фоновом режиме, но иногда обновлял интерфейс через завершения обработчиков. При переходе на Swift 6 в своем новом приложении для потребительских банковских услуг (Модуль A) им нужно было гарантировать, что все обновления интерфейса происходят на MainActor без немедленного переписывания всего SDK. Они рассматривали три подхода для решения проблемы изоляционной границы.
Первый вариант заключался в синхронном переписывании SDK для использования ** Swift** 6 акторов и типов Sendable. Хотя это обеспечивало бы безопасность на этапе компиляции и нулевые накладные расходы во время выполнения, стоимость проектирования была бы непомерной — оценка составляла три месяца — и вводила бы высокий риск регрессии в критической логике вычислений. Второй вариант включал ручное обертывание каждого обратного вызова SDK в DispatchQueue.main.async в точках вызова в Модуле A. Этот подход был явным и не требовал изменений в SDK, но производил хрупкий, разбросанный «шаблонный код», который легко пропустить, что могло привести к потенциальным гонкам данных, когда новые разработчики добавляли функции. Третий вариант использовал аннотации @preconcurrency в публичном интерфейсе SDK в сочетании с требованиями изоляции MainActor.
Команда выбрала третье решение, аннотируя наследуемые обратные вызовы как @preconcurrency @MainActor. Это позволило Модулю A вызывать эти методы с уверенностью, что среда выполнения Swift будет динамически проверять контекст исполнителя в переходный период. Когда происходили нарушения — например, если фоновый поток пытался вызвать обратный вызов интерфейса — приложение немедленно выдавало ошибку при отладочных сборках с четкими диагностическими сообщениями, позволяя разработчикам постепенно выявлять и устранять предположения о потоках. После полной миграции SDK на строгий параллелизм они удалили @preconcurrency, чтобы обеспечить исключительно статическую изоляцию, в результате чего был получен код с нулевыми проверками изоляции во время выполнения и гарантированной безопасностью потоков.
Чего часто не замечают кандидаты
Как @preconcurrency влияет на искаженное имя символа функции в ABI и почему это важно для динамической компоновки?
@preconcurrency не изменяет искаженное имя символа или низкоуровневое соглашение о вызове функции, поскольку требования к изоляции кодируются в метаданных типов и таблицах свидетельств, а не в самом символе. Этот дизайн имеет решающее значение для стабильности ABI, поскольку он позволяет авторам библиотек добавлять изоляцию актора к существующим публичным API, не нарушая бинарную совместимость с ранее скомпилированными клиентами. Динамические проверки внедряются в точке вызова или в начальной точке компилятором на основе метаданных, обеспечивая возможность старых бинарных файлов бесшовно связываться с новыми библиотеками с учетом изоляции.
В чем разница между экземпляром глобального актора shared, объявленным как let, и как это влияет на уникальность исполнителя?
Протокол GlobalActor требует статического свойства shared, которое возвращает базовый экземпляр актора, и это свойство должно быть объявлено как let, чтобы гарантировать единственный уникальный последовательный исполнитель на уровне процесса. Если бы shared был объявлен как var, то исполнитель теоретически мог бы быть заменен во время выполнения, что нарушило бы основной инвариант глобального актора, обеспечивающего единую последовательную очередь для всех изолированных операций, что потенциально могло бы вызвать гонки данных и разрушить границы изоляции. Компилятор Swift обеспечивает это требование, требуя, чтобы shared было статическим неизменяемым свойством, тем самым гарантируя, что swift_task_isCurrentExecutor всегда сравнивает с постоянным, уникальным объектом исполнителя.
Когда функция изолирована к глобальному актеру, почему компилятор иногда вызывает переход к исполнителю, даже когда вызывается изнутри того же актора, и как модификатор параметра isolated оптимизирует это?
Компилятор выполняет переход к исполнителю — или, по крайней мере, проверку во время выполнения — когда он не может статически доказать, что вызывающая сторона уже выполняется на исполнителе целевого глобального актора, что обычно происходит на границах модулей или при вызове через экзистенциальные типы, где информация об изоляции стирается. Этот консервативный подход обеспечивает безопасность, но влечет за собой накладные расходы на синхронизацию. Разработчики могут оптимизировать это, используя модификатор параметра isolated (например, func process(isolation: isolated MainActor = #isolation)), который явно передает контекст изоляции вызывающего как аргумент; это позволяет компилятору исключить проверку во время выполнения и переход, когда вызывающий доказывает, что он находится на том же исполнителе, уменьшая вызов до прямого вызова функции без расходов на переключение контекста.