Swift iOS - DispatchWorkItem все еще работает, хотя он отменяется и устанавливается на ноль

Эта процедура отмены не делает того, что, как я подозреваю, вы думаете. При отмене DispatchWorkItem упреждающая отмена не выполняется. Это, конечно, не имеет никакого отношения к вызову updateChildValues. Все, что он делает, — это выполняет поточно-безопасную настройку свойства isCancelled, которую, если вы вручную выполняете итерацию в цикле, вы можете периодически проверять и преждевременно выходить, если видите, что задача была отменена.

В результате проверка isCancelled в начале задачи не очень полезная схема, потому что, если задача еще не создана, отменять нечего. Или, если задача была создана и добавлена ​​в очередь и отменена до того, как очередь успела запуститься, очевидно, что она просто будет отменена, но никогда не будет запущена, и вы никогда не доберетесь до своего isCancelled теста. И если задача запущена, она, скорее всего, прошла тест isCancelled до вызова cancel.

Суть в том, что попытки рассчитать время запроса cancel так, чтобы он был получен точно после запуска задачи, но до того, как он дошел до теста isCancelled, будут бесполезными. У вас есть гонка, которую будет почти невозможно точно рассчитать. Кроме того, даже если вам удалось правильно рассчитать время, это просто демонстрирует, насколько неэффективен весь этот процесс (только 1 из миллиона cancel запросов сделает то, что вы намеревались).

Как правило, если у вас есть асинхронная задача, которую вы хотите отменить, вы должны обернуть ее в асинхронный пользовательский подкласс Operation и реализовать метод cancel, который останавливает базовую задачу. Очереди операций просто предлагают более изящные шаблоны для отмены асинхронных задач, чем очереди отправки. Но все это предполагает, что базовая асинхронная задача предлагает механизм для ее отмены, и я не знаю, предлагает ли вообще Firebase значимый механизм для этого. Я, конечно, не видел, чтобы это рассматривалось ни в одном из их примеров. Так что все это может быть спорным.

Я предлагаю вам отойти от конкретного шаблона кода в вашем вопросе и описать, чего вы пытаетесь достичь. Давайте не будем останавливаться на вашей конкретной попытке решения вашей более широкой проблемы, а скорее давайте поймем, какова более общая цель, а затем мы сможем поговорить о том, как ее решить.

Кроме того, в вашем примере есть и другие технические проблемы.

В частности, я предполагаю, что вы запускаете это в основной очереди. Поэтому task.perform() немедленно запускает его в текущей очереди. Но ваш DispatchQueue.main.asyncAfter(...) может быть запущен только тогда, когда все, что выполняется в основной очереди, выполнено. Таким образом, даже если вы указали задержку в 0,0000000001 секунды, она на самом деле не будет работать до тех пор, пока не будет доступна основная очередь (а именно, после того, как ваш perform завершит работу в основной очереди, и вы пройдете тест isCancelled).

Если вы хотите проверить эту гонку между выполнением задачи и ее отменой, вам нужно выполнить отмену в другом потоке. Например, вы можете попробовать:

weak var task: DispatchWorkItem?

let item = DispatchWorkItem {
    if (task?.isCancelled ?? true) {
        print("canceled")
    } else {
        print("not canceled in time")
    }
}

DispatchQueue.global().asyncAfter(deadline: .now() + 0.00001) {
    task?.cancel()
}

task = item
DispatchQueue.main.async {
    item.perform()
}

Теперь вы можете поиграть с различными задержками и увидеть различное поведение между задержкой в ​​0,1 секунды и задержкой в ​​0,0000000001 секунды. И вы захотите убедиться, что приложение достигло состояния покоя, прежде чем пытаться выполнить этот тест (например, сделайте это в событии нажатия кнопки, а не в viewDidLoad).

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

weak var task: DispatchWorkItem?

let queue = DispatchQueue(label: "com.domain.app.queue") // create a queue for our test, as we never want to block the main thread

let semaphore = DispatchSemaphore(value: 0)

let item = DispatchWorkItem {
    // You'd never do this in a real app, but let's introduce a delay
    // long enough to catch the `cancel` between the time the task started.
    //
    // You could sleep for some interval, or we can introduce a semphore
    // to have it not proceed until we send a signal.

    print("starting")
    semaphore.wait() // wait for a signal before proceeding

    // now let's test if it is cancelled or not

    if (task?.isCancelled ?? true) {
        print("canceled")
    } else {
        print("not canceled in time")
    }
}

DispatchQueue.global().asyncAfter(deadline: .now() + 0.5) {
    task?.cancel()
    semaphore.signal()
}

task = item
queue.async {
    item.perform()
}

Вы бы никогда этого не сделали, но это просто показывает, что isCancelled действительно работает.

Честно говоря, вы бы никогда не использовали isCancelled таким образом. Обычно вы используете процесс isCancelled, если выполняете какой-то длительный процесс, в котором вы можете периодически проверять статус isCancelled и выходить, если он верен. Но в вашей ситуации это не так.

Вывод из всего этого состоит в том, что проверка isCancelled в начале задачи вряд ли когда-нибудь даст то, на что вы надеялись.