Swift 6: Sendable для C-колбэков и MultitouchSupport

Да, подход с @unchecked Sendable для класса вроде MultitouchManager в swift 6 — правильный и рекомендуемый для интеграции C-колбэков из приватных фреймворков типа MultitouchSupport.framework, где нет контроля над потоком (mt_ThreadedMTEntry). В swift concurrency это подавляет предупреждения о non-sendable типах, если добавить внутренние блокировки (NSLock или Mutex) и проверки вроде dispatchPrecondition. Эксперты советуют комбинировать с @MainActor для UI-обновлений или structured concurrency, чтобы избежать data races в строгой проверке sendable swift.

Содержание

• Swift 6 и swift concurrency: что нового в строгой проверке
• Протокол Sendable в swift 6: требования и автоматическая infer
• Проблемы с C-колбэками и non-sendable closures в swift concurrency
• @unchecked Sendable: когда и как использовать безопасно
• Пример интеграции MultitouchSupport.framework с sendable swift
• Альтернативы @unchecked Sendable: Mutex, @MainActor и structured concurrency
• Миграция на Swift 6: шаги и лучшие практики
• Источники
• Заключение

Swift 6 и swift concurrency: что нового в строгой проверке

Swift 6 меняет правила игры в swift concurrency. Если раньше targeted concurrency checking позволял игнорировать некоторые data races, то теперь strict mode — это норма. Компилятор требует, чтобы все типы между акторами передавались как Sendable, иначе вылетит предупреждение или ошибка. Зачем это нужно? Представьте: ваш колбэк из MultitouchSupport срабатывает в фоновом потоке, а состояние класса обновляется без синхронизации. Boom — race condition.

В официальной документации Apple подчеркивают: включите complete concurrency checking в проекте, и swift 6 выявит все слабые места. Для macOS 15+ это критично, особенно с приватными API. Но не паникуйте — миграция gradual, с флагами вроде -strict-concurrency=complete.

А теперь подумайте: ваш MultitouchManager держит currentFingerCount. Без Sendable компилятор заругается на захват в closure. Решение? Мы к нему подойдем.

Протокол Sendable в swift 6: требования и автоматическая infer

Sendable — это протокол, гарантирующий, что значение можно безопасно передавать между concurrency domains (акторами, задачами, потоками). В swift 6 inferring стал умнее: value types вроде структур часто получают его автоматически, если поля Sendable. Классы? Нет, они reference types — требуют явной аннотации.

Что внутри? Два требования:

• Нет мутабельного состояния или оно защищено (locks, actors).
• Нет non-atomic операций.

Для C-колбэков типа MTContactCallbackFunction infer не сработает — это @convention(c), не Sendable по умолчанию. В блоге Jesse Squires объясняют: такие closures нельзя пометить @Sendable, потому что фреймворк не дает гарантий. Результат? Ваш код компилируется, но с warning: “Capture of ‘self’ with non-sendable type”.

Коротко: sendable swift — это не опция, а требование для будущего-proof кода. Ваш класс с NSLock уже близок.

Проблемы с C-колбэками и non-sendable closures в swift concurrency

C-колбэки — вечная боль swift concurrency. MTRegisterContactFrameCallback регистрирует функцию, которая fires в mt_ThreadedMTEntry — неизвестном фоновом потоке. Захват MultitouchManager.shared в closure? Компилятор видит non-sendable класс и кричит: “Potential data race”.

Почему так? Legacy API не знает о Sendable. Вы не можете изменить сигнатуру на @Sendable @convention(c) — это сломает биндинги. Плюс, UnsafeMutableRawPointer для touches — чистый unsafe код, где concurrency не поможет.

На Stack Overflow обсуждают похожий кейс с Timer: переходите на structured concurrency или @unchecked. Для multitouch то же — фреймворк приватный, так что App Store не проблема, но data races — да.

Ваш текущий код с fingerCountLock решает мутации. Но компилятор все равно ворчит. Время к @unchecked Sendable.

@unchecked Sendable: когда и как использовать безопасно

@unchecked Sendable — это “я обещаю компилятору, что thread-safe”. Идеально для legacy вроде вашего. Когда применять?

• Legacy C-API с колбэками.
• Внутренние locks/atomic обеспечивают безопасность.
• Нет публичных мутаций без sync.

Fatbobman приводит пример ThreadSafeCache: concurrent queue + barrier. Добавьте dispatchPrecondition(condition: .notOnQueue(.main)) в колбэк — и вуаля, доказательство, что не на main.

Ваш код уже хорош:

final class MultitouchManager: @unchecked Sendable {
 // locks как есть
}

Но улучшите: используйте OSAllocatedUnfairLock вместо NSLock (быстрее) или Mutex из Swift 6. И документируйте: “Thread-safe via locks”.

Безопасно? Да, если locks покрывают все состояние. Иначе — crash в проде.

Пример интеграции MultitouchSupport.framework с sendable swift

Вот полный, улучшенный пример для вашего случая. Добавил dispatchPrecondition, Mutex и @MainActor для UI.

import Foundation
import Dispatch // для Mutex в Swift 6

actor TouchProcessor {
 private var touches: [CGPoint] = []
 func process(_ touchesPtr: UnsafeMutableRawPointer?, count: Int32) {
 // Обработка на акторе — safe
 }
}

final class MultitouchManager: @unchecked Sendable {
 static let shared = MultitouchManager()
 
 private let lock = Mutex() // Swift 6 Mutex — true Sendable
 private var _currentFingerCount: Int = 0
 private let processor = TouchProcessor()
 
 var currentFingerCount: Int {
 lock.withLock { _currentFingerCount }
 }
 
 private init() {}
 
 func deviceDidReceiveTouches(_ touches: UnsafeMutableRawPointer?, count: Int32) {
 dispatchPrecondition(condition: .notOnQueue(.main)) // Проверка потока
 
 Task { @MainActor in
 // UI обновления — safe
 print("Fingers: (count)")
 }
 
 Task { await processor.process(touches, count: count) }
 
 lock.withLock {
 _currentFingerCount = Int(count)
 }
 }
}

// Колбэк
let callback: MTContactCallbackFunction = { device, touches, count, _, _ in
 MultitouchManager.shared.deviceDidReceiveTouches(touches, count: count)
 return 0
}

// Setup
if let device = MTDeviceCreateDefault() {
 MTRegisterContactFrameCallback(device, callback)
 MTDeviceStart(device, 0)
}

Это компилируется чисто в swift 6. Mutex делает класс ближе к real Sendable.

Альтернативы @unchecked Sendable: Mutex, @MainActor и structured concurrency

Не хотите @unchecked? Окей, варианты:

1. Actor вместо класса: actor MultitouchManager. Колбэк диспатчит Task { await manager.process() }. Минус: overhead.
2. @MainActor: Если все на main. Но ваш поток фоновый — используйте MainActor.assumeIsolated() с риском.
3. Structured concurrency: AsyncSequence для touches вместо колбэка. Но для legacy — сложно.
4. Mutex из Synchronization: Как в примере — заменяет NSLock, делает @unchecked safer.

На Swift Forums советуют @MainActor для single-threaded. Для multitouch Mutex + Task — золотая середина.

Выберите по нагрузке: 120Hz touches? Actor overhead съест CPU.

Миграция на Swift 6: шаги и лучшие практики

Шаги для вашего проекта:

1. Xcode 16+, target macOS 15.
2. Build Settings: SWIFT_STRICT_CONCURRENCY = complete.
3. Фиксите warnings: @Sendable closures, actors для state.
4. Тестируйте с Thread Sanitizer.
5. Instruments для races.

Swift.org рекомендует gradual: сначала warning, потом error. Для приватных API — @unchecked окей.

Лучшие практики: всегда nonisolated где можно, Task.detached для legacy. И профилируйте — multitouch генерит тонну событий.

Источники

1. Jesse Squires — Swift concurrency и non-sendable closures для C-колбэков: https://www.jessesquires.com/blog/2024/06/05/swift-concurrency-non-sendable-closures/
2. Fatbobman — Sendable и @unchecked Sendable с примерами Mutex: https://fatbobman.com/en/posts/sendable-sending-nonsending/
3. Stack Overflow — Избегание Sendable для колбэков в Swift 6 API: https://stackoverflow.com/questions/79155218/avoiding-sendable-for-callbacks-in-timer-based-swift-6-api-manager
4. Apple Developer Documentation — Миграция на Swift 6 и strict concurrency: https://developer.apple.com/documentation/swift/adoptingswift6
5. Swift.org — Документация по swift concurrency и Sendable: https://www.swift.org/documentation/concurrency/
6. Swift Forums — Обсуждение Swift 6 concurrency и @MainActor: https://forums.swift.org/t/questions-about-swift-6-concurrency/82045

Заключение

В swift 6 ваш подход с @unchecked Sendable, блокировками и dispatchPrecondition — верный для MultitouchSupport.framework. Добавьте Mutex или actor для пущей безопасности, и код будет future-proof. Главное — тестируйте на races, и multitouch-утилита полетит гладко даже в строгой swift concurrency. Если нагрузка высокая, structured альтернативы сэкономят нервы. Удачи с macOS-приложением!