Создается ли Run Loop для каждой очереди?

Подробный разбор взаимосвязи Run Loop и очередей (Dispatch Queues)

Нет, Run Loop не создается автоматически для каждой очереди (Dispatch Queue). Это распространенное заблуждение, возникающее из-за смешения двух разных концепций в iOS/macOS разработке: Run Loop (цикл выполнения) и Dispatch Queue (очередь Grand Central Dispatch). Они представляют различные механизмы управления потоком выполнения и имеют принципиально разные модели работы.

Ключевые различия Run Loop и Dispatch Queue

1. Run Loop — это паттерн проектирования (часть инфраструктуры потоков), тесно связанный с конкретным NSThread. Его основная задача — организовать работу потока, планируя обработку различных источников событий (input sources) и таймеров (timers). Run Loop работает в модели "событие -> ожидание -> обработка".
2. Dispatch Queue — это абстракция уровня GCD (Grand Central Dispatch) для выполнения задач (tasks/blocks). Очередь не привязана напрямую к конкретному потоку. GCD управляет пулом потоков, и задачи из очередей выполняются на доступных потоках из этого пула. Очередь — это, прежде всего, механизм для постановки задач в очередь (FIFO) и управления их выполнением (серийно или параллельно).

Run Loop: привязка к потоку

У каждого потока может быть свой собственный Run Loop, но он не создается по умолчанию. Его нужно при необходимости получить и запустить. Главный поток (main thread) имеет уже запущенный Run Loop, что является фундаментом для работы всего UI и обработки событий.

// Пример: Получение Run Loop для текущего потока
let currentRunLoop = RunLoop.current

// Run Loop для главного потока
let mainRunLoop = RunLoop.main

// Запуск Run Loop в текущем потоке (обычно не делается вручную для GCD очередей)
// currentRunLoop.run() // Это заблокирует поток!

Dispatch Queue: отсутствие своего Run Loop

GCD очереди (как серийные, так и параллельные) не имеют и не создают собственных Run Loop. Они выполняют задачи на потоках из общего пула.

let serialQueue = DispatchQueue(label: "com.example.serial")
let concurrentQueue = DispatchQueue(label: "com.example.concurrent", attributes: .concurrent)

// Эта задача будет выполнена на одном из фоновых потоков пула GCD.
// У этого потока, скорее всего, НЕТ активного Run Loop.
serialQueue.async {
    print("Выполняется на потоке из пула GCD: \(Thread.current)")
    // Попытка использовать RunLoop.current здесь, скорее всего, будет бесполезной,
    // так как Run Loop не запущен, и таймеры/источники на нем не будут работать.
}

Практическое следствие: Таймеры на очередях

Это различие ярко проявляется при работе с таймерами. Timer для своей работы требует активного Run Loop.

// ПРАВИЛЬНО: Таймер зарегистрирован в Run Loop главного потока.
// Он будет корректно срабатывать, так как main Run Loop активен.
DispatchQueue.main.async {
    let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
        print("Таймер на главной очереди")
    }
    // Таймер автоматически добавляется в текущий RunLoop (.main)
}

// НЕПРАВИЛЬНО/НЕ РАБОТАЕТ: Попытка запустить стандартный таймер на фоновой GCD очереди.
let backgroundQueue = DispatchQueue(label: "com.example.timer")
backgroundQueue.async {
    // RunLoop.current для этого потока НЕ активен.
    let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
        print("Этот код, скорее всего, никогда не выполнится")
    }
    // Таймер добавлен в неактивный RunLoop. Чтобы он работал, нужно вручную запустить цикл (run()),
    // но это заблокирует текущий поток, что противоречит концепции GCD очередей.
    // RunLoop.current.run() // Блокировка!
}

// РЕШЕНИЕ: Использование DispatchSourceTimer для таймеров на очередях GCD.
let timerQueue = DispatchQueue(label: "com.example.dispatchTimer")
let dispatchTimer = DispatchSource.makeTimerSource(queue: timerQueue)
dispatchTimer.schedule(deadline: .now(), repeating: 1.0)
dispatchTimer.setEventHandler {
    print("DispatchTimer сработал на очереди \(timerQueue.label)")
}
dispatchTimer.resume()
// DispatchSourceTimer не зависит от Run Loop и использует механизмы ядра.

Итог и выводы

• Run Loop создается на уровне потока (Thread), а не очереди (Queue).
• Главный поток имеет всегда активный Main Run Loop.
• Фоновые потоки, создаваемые или используемые GCD, по умолчанию не имеют активного Run Loop.
• Dispatch Queue — это абстракция для планирования задач, которая использует потоки из пула. Сама очередь не является потоком и не владеет Run Loop.
• Для периодических задач на фоновых очередях следует использовать DispatchSourceTimer, а не Timer, который зависит от Run Loop.

Таким образом, связь "одна очередь — один Run Loop" является ошибочной. Правильная ментальная модель: "у потока может быть Run Loop, а очередь планирует задачи на выполнении на доступных потоках".