NSRunLoop's runMode:beforeDate: - правильный подход для установки beforeDate

Код в документах :

Причина, по которой я спрашиваю об этом, заключается в том, что [NSDate DistanceFuture] — это дата, охватывающая пару столетий.

Метод runMode:beforeDate: будет

• немедленно вернуть NO, если нет источников, запланированных на RunLoop.

• возвращать YES всякий раз, когда событие было обработано.

• вернуть YES, когда будет достигнуто limitDate.

Таким образом, даже если limitDate очень высокое, оно будет возвращаться после каждого обработанного события и не будет продолжать работать, пока не будет достигнуто limitDate. Это будет ждать так долго, только если никакое событие никогда не будет обработано. Таким образом, limitDate подобен тайм-ауту, после которого метод перестанет ждать, пока произойдет событие. Но если вы хотите обрабатывать несколько событий в строке, вы должны вызывать этот метод снова и снова, отсюда и цикл.

Подумайте о получении пакетов с тайм-аутом из сетевого сокета. Вызов fetch возвращается, когда приходит пакет или когда истекает тайм-аут. Тем не менее, если вы хотите обработать следующий пакет, вы должны снова вызвать метод выборки.

Следующий код, к сожалению, довольно плохой по двум причинам:

// BAD CODE! DON'T USE!
NSDate * distFuture = NSDate.distantFuture;
NSRunLoop * runLoop = NSRunLoop.currentRunLoop;
while (keepRunning) {
    [runLoop runMode:NSDefaultRunLoopMode beforDate:distFuture];
}

1. Если RunLoopSource еще не запланировано для RunLoop, он будет тратить 100% процессорного времени, так как метод вернется сразу же, чтобы вызвать его снова, и так быстро, как ЦП сможет это сделать.

2. AutoreleasePool никогда не продлевается. Объекты, которые автоматически освобождаются (и даже ARC делает это), добавляются в текущий пул, но никогда не освобождаются, поскольку пул никогда не очищается, поэтому потребление памяти будет увеличиваться, пока выполняется этот цикл. Насколько многое зависит от того, что на самом деле делают ваши RunLoopSources и как они это делают.

Лучшей версией будет:

// USE THIS INSTEAD
NSDate * distFuture = NSDate.distantFuture;
NSRunLoop * runLoop = NSRunLoop.currentRunLoop;
while (keepRunning) @autoreleasepool {
    BOOL didRun = [runLoop runMode:NSDefaultRunLoopMode beforDate:distFuture];
    if (!didRun) usleep(1000);
}

Он решает обе проблемы:

• AutoreleasePool создается при первом запуске цикла и очищается после каждого запуска, поэтому потребление памяти со временем не увеличивается.

• В случае, если RunLoop на самом деле вообще не запустился, текущий поток приостанавливается на одну миллисекунду перед новой попыткой. Таким образом, загрузка ЦП будет довольно низкой, поскольку, поскольку RunLoopSource не установлено, этот код выполняется только один раз в миллисекунду.

Чтобы надежно завершить цикл, вам нужно сделать две вещи:

1. Установите keepRunning на NO. Обратите внимание, что вы должны объявить keepRunning как volatile! Если вы этого не сделаете, компилятор может оптимизировать проверку и превратить ваш цикл в бесконечный цикл, поскольку он не видит кода в текущем контексте выполнения, который когда-либо мог бы изменить переменную, и он не может знать, что какой-то другой код где-то еще ( а может и в другой ветке) может в фоновом режиме изменить. Вот почему в этих случаях вам обычно нужен барьер памяти (блокировка, мьютекс, семафор или атомарная операция), поскольку компиляторы не оптимизируют эти барьеры. Однако в этом простом случае достаточно использовать volatile, так как BOOL всегда является атомарным в Obj-C, а volatile говорит компилятору Всегда проверять значение этой переменной, так как оно может измениться за вашей спиной, и вы не увидите этого изменения при компиляции. время.

2. Если переменная была изменена из другого потока, а не из обработчика событий, ваш поток RunLoop может находиться в спящем режиме внутри вызова runMode:beforeDate:, ожидая возникновения события RunLoopSource, которое может занять любое время или вообще никогда не произойти. Чтобы заставить этот вызов вернуться немедленно, просто запланируйте событие после изменения переменной. Это можно сделать с помощью performSelector:onThread:withObject:waitUntilDone:, как показано ниже. Выполнение этого селектора считается событием RunLoop, и метод вернется после вызова селектора, увидит, что переменная изменилась, и выйдет из цикла.

volatile BOOL keepRunning;

- (void)wakeMeUpBeforeYouGoGo {
    // Jitterbug
}

// ... In a Galaxy Far, Far Away ...
    keepRunning = NO;
    [self performSelector:@selector(wakeMeUpBeforeYouGoGo) 
        onThread:runLoopThread withObject:nil waitUntilDone:NO];