Длительные операции + QtConcurrent

[Nidxogg]

Добрый день.

Есть gui-программа, работающая с БД. Все запросы и т.д вынесены в отдельный класс.
Все работает в одном потоке.

Есть такой псевдокод, который должен выполнится строго в заданной последовательности.

Код:

void MyClass::myMethod()
{
    func1();
    func2();
    func3();
}

Собственно func2() выполняется довольно долго, поэтому решил на время фриза интерфейса добавить гифку-прогрессбар(+QMovie) .
Гифка, естественно, не анимируется в процессе выполнения func2(). processEvent() не помог.

Тогда решил выполнить func2() в отдельном потоке с использованием QtConcurrent::run(...), гифка ожила, но теперь func3() начинает выполняться до окончания func2();
Пробовал использовать waitForFinished, но опять столкнулся с фризом интерфейса.

Может у кого-нибудь есть идеи как выйти из ситуации?

[Bepec]

Видимо вы как то не так делали processEvents Всё должно работать без фризов.

[Old]

Запускайте func3 в слоте, который будет вызываться при завершении потока, выполняющего func2.

[Nidxogg]

Запускайте func3 в слоте, который будет вызываться при завершении потока, выполняющего func2.

Вы имеет ввиду соединить сигнал finished() от QFutureWatcher со слотом, и вызывать func3() там?

прим.: мне приходит несколько пакетов по сети практически одновременно, которые необходимо обработать.
В слоте я вызываю myMethod и рассчитываю, что обработка следующего пакета не начнется, пока не завершится обработка текущего (собственно так и работает, т.к все в одном потоке(если без QtConcurent)).  
Не получился ли, что я вызову myMethod раньше, чем завершится выполнение func3()?

Видимо вы как то не так делали processEvents Всё должно работать без фризов.

У меня прозрачный виджет ставится, аналог вашего sbglass (qlightboxwidget в гугле), на который кидается QLabel и гифка.
processEvents вызываю qApp->processEvents() во время обработки запроса из БД  (Порядка 150 раз в течение ~5 секунд);

[Igors]

Гифка, естественно, не анимируется в процессе выполнения func2(). processEvent() не помог.

Не вижу здесь ничего естественного, надо разбираться. Вообще запуск потока только с целью обеспечить индикатор не есть хорошо/грамотно.

[Nidxogg]

Не вижу здесь ничего естественного, надо разбираться

Главный поток загружен операциями в func2, интерфейс зафрижен.
Что не так?

[Bepec]

Не так, что достаточно 25 раз в секунду вызывать processEvents чтобы пользователь вообще ничего не заподозрил.
Значит вы его вызываете или не там, или не так

Т.е. вот такое высказывание верно:
Главный поток загружен операциями в func2, где вызывается processEvents, интерфейс работает нормально.

[VPS]

Что Вам мешает все три метода обработки данных запускать последовательно в отдельном потоке, а принимаемые пакеты из главного (GUI или другого) потока передавать туда на обработку? В данном случае, для передачи пакетов, можно попробовать использовать сигналы или библиотеку, в которой есть потокобезопасная очередь. Т.е. получится что-то типа шаблона Producer-Consumer.

[Igors]

Главный поток загружен операциями в func2, интерфейс зафрижен.
Что не так?

А что "так"? То что есть интенсивный расчет - еще не основание выносить его в отдельный поток. Вот напр если 2 расчета параллельно - тогда да. А так гораздо проще вызывать processEvents в теле расчета. 25 раз в сек - ну это для видео, а для UI достаточно и 5 раз. Попробуйте вместо гифки напр QProgressDialog, убедитесь что он работает, а потом и до гифки дело дойдет.

[qate]

QtConcurrent::run(myMethod) - не ?
вызывать руками процессевентс - это самому себе грабли раскидывать

[OKTA]

Если планируется расширение в дальнейшем, то вынеси весь класс работы с БД в отдельный поток и не мучайся, а то так или processEvents везде распихивать или QtConcurrent::run постоянно дергать, если появятся новые тяжелые функции.

[Old]

или QtConcurrent::run постоянно дергать, если появятся новые тяжелые функции.

Ну так он именно для этого и сделан.
Он запускает пул потоков и нагружает их когда в этом есть необходимость.

[OKTA]

Так-то да, но когда их много, могут быть проблемы с управлением 

[Old]

Так-то да, но когда их много, могут быть проблемы с управлением 

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

[OKTA]

Это в идеальном варианте 
А так, например большая проблема QtConcurrentRun, что не остановишь его человеческим способом, когда потребуется. Вызывает геморрой, которого можно избежать, выделив все это барахло в честный отдельный поток 
Во всяком случае лично меня всегда это коробило и я стараюсь пользоваться QtConucrrentRun только в случае небольших функций