Обработчик синхронного завершения чтения UIDocument застопорился при отправке

#ios #grand-central-dispatch #synchronous #uidocument

#iOS #гранд-сентрал-диспетчерская #синхронный #uidocument

Вопрос:

Я попробовал несколько способов переноса файла, прочитанного в вызове синхронного метода (включая использование нескольких очередей, указание целевых очередей, настройку NSThread и сигнализацию с помощью NSCondition, даже перемещение выделения UIDocument в фоновый поток в конце, а также попытку dispatch_sync в фоновой очереди).

То, что постоянно происходило, — это обработчик завершения для UIDocument.openWithCompletionHandler не выполнялся, хотя в документации указано, что это должно произойти в той же очереди, которая инициировала вызов openWithCompletionHandler.

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

Мой вариант использования требует синхронного чтения файлов (с очень небольшими размерами данных), и я бы предпочел удобство UIDocument переходу к методам более низкого уровня или поиску способов введения асинхронных шаблонов. Я считаю, что UIDocument был разработан для более обычных случаев, я достаточно хорошо понимаю повсеместность и в большинстве случаев удобство и эффективность асинхронных шаблонов, но в этом случае это создало бы громоздкую ситуацию как для разработки, так и для пользовательского опыта.

Интересно, есть ли что-то еще, что можно было бы попробовать с очередями отправки, которые все еще можно изучить (например, ручное использование событий из очереди, создание пользовательского цикла запуска), что могло бы избежать этого, казалось бы, глобального эффекта синхронизации.

ПРАВКА: это для расширения приложения аудиоустройства. Создание экземпляра контролируется платформой, и состояние «наполовину инициализировано» может стать проблемной ситуацией. Это в значительной степени стандарт в отрасли, чтобы полностью загрузить плагин, прежде чем даже позволить хост-приложению начать воспроизведение любого звука, например, не говоря уже о том, чтобы начать транслировать события MIDI/автоматизации. (Это не значит, что нет расширений с сумасшедшим временем загрузки, которые могли бы еще раз взглянуть на их дизайн, но в большинстве случаев они вполне оправданы в этой области).

Комментарии:

1. Тебе действительно не стоит с этим бороться. Если вы поддерживаете iOS 13 , вы скоро сможете использовать Async/Await для более простой асинхронной семантики. Ваши проблемы в том, что вы почти наверняка в конечном итоге заблокируете основной поток, если попытаетесь сделать все синхронным. В конечном счете вам нужно вернуть свои данные в основную очередь. Вы не можете отправлять сообщения синхронно в основной очереди, поэтому эта часть должна быть асинхронной. Если это асинхронно, то вы можете просто сделать это правильно и дождаться завершения.