IOS semaphore_wait_trap в основном потоке, вызывающий зависание в пользовательском интерфейсе

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

semaphore_wait_trap()

в главном потоке (Очередь)

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

После отмены приостановки рабочего потока графический интерфейс реагирует на 1-2 секунды (я подозреваю, что этот поток снова активируется), а затем пользовательский интерфейс снова перестает отвечать.

Эта тема не делаетdispatch_sync() звонки в основной поток / очередь

Возможно ли, что IOS приостанавливает основной поток ("ловушки» это) потому что рабочий долго бежит?

Могу ли я заставить его снять блок ??

Я добавляю несколько экранов печати из стека режима отладки.

Прежде чем приостановить зависание очереди:

И висящая нить:

И после приостановки и приостановки плохой очереди:

 Warren Burton22 окт. 2015 г., 16:57
Является "pixtr» вы или сторонний продукт? , Если это третье лицо, я хотел бы рассмотреть возможность его отключения от вашего интерфейса, чтобы увидеть, если это проблема
 Rob Napier29 апр. 2016 г., 16:05
Там'здесь не так много времени (в частности, я нене знаю чтовadd_blob), так что лучшее, что у меня есть, это догадки. Я подозреваю, что тыповторно передать неправильные флагиcvFloodFill и это приводит к зависанию графического процессора. Поскольку UIKit также хочет, чтобы графический процессор использовался для вычисления прокрутки (DYTransport - это частная среда, связанная с вычислениями на GPU), это приводит к зависанию UIKit в ожидании появления графического процессора.

Ответы на вопрос(2)

Возможно ли, что IOS приостанавливает основной поток ("ловушки» это) потому что рабочий долго бежит? - нет Я думаю, что ваша проблема связана с рисованием или изменением некоторых элементов пользовательского интерфейса. Не все функции могут быть вызваны из фонового потока (например, изменения в элементах пользовательского интерфейса должны выполняться в основном потоке.). В вашей последовательной очереди, если какой-либо метод должен изменить элементы пользовательского интерфейса, вы должны вызвать его в главном потоке, например

dispatch_async(dispatch_get_main_queue(), ^{
                //do some main thread job here
            });
)
 Avner Barr20 нояб. 2012 г., 15:32
делаю dispatch_queue_create ("worker_queue», DISPATCH_QUEUE_SERIAL);
 Avner Barr20 нояб. 2012 г., 15:30
Я неделать какие-либо пользовательские вызовы из фонового рабочего потока.
 Avner Barr20 нояб. 2012 г., 15:33
dispatch_async (my_queue, {рабочий блок с обратным вызовом по завершении}) I '
 Avner Barr20 нояб. 2012 г., 21:51
используя графический процессор в рабочем потоке. Может ли это повесить основной поток? Если так, то как это сделать?
 Fahri Azimov21 нояб. 2012 г., 06:50
Я использовал OpenCV так же, как вы, и была проблема, с которой вы столкнулись. В моем случае проблема заключалась в том, что я использовал функции Core Graphics в фоновом потоке. Вы должны предоставить код блока отправки и код методов, которые вы вызываете в блоке, чтобы мы могли вам помочь.

Может быть, вы просто забыли сохранить переменную в вызове функции dispatch (Что касается меня, я опускал статическое ключевое слово до объявления dispatch_once_t и диспетчеризация может 'т процесс с встроенной функцией). Трассировка стека была такой же, как ваша. Это была моя вина.

+ (instancetype)sharedInstance
{
    (static was omitted) dispatch_once_t once;
    static id sharedInstance;
    dispatch_once(&once, ^{
        sharedInstance = [[self alloc] init];
    });
    return sharedInstance;
} 

Ваш ответ на вопрос