Russian Qt Forum

Всем доброго времени.

Вот, есть некая ф-я, на работу которой затрачивается 1-2 мсек. Есть ли необходимость выноса ее в отдельный поток?
И есть ли вообще рекомендации, когда это нужно делать (каков лимит микросекунд/миллисекунд) чтобы ГУЙ не тормозил? :)

Обычно считается, что от 20 обновлений в секунду человеку трудно увидеть разницу.
Поэтому 50 мсек на функцию - должно быть в пределах нормы.

По моим наблюдениям рекомендация "выноси в поток" дается на все без разбора, мотивировка "чтобы UI не тормозило". Думаю выносить или нет зависит от того есть ли что делать приложению пока ф-ция выполняется. Напр если операция чисто фоновая и может длиться хз сколько, то вынос очевиден. Но часто (если не чаще) бывает что приложению надо дождаться конца или отмены операции, а потом уже что-то решать. Здесь вынос в поток совершенно ни к чему, заморозку UI легко решить повтыкав qApp->processEvents

Читаем классику  :)
Где-то еще видел: задержка до 2 сек - можно обойтись курсором, больше - надо показывать индикатор

Не, ну это понятно... А вот, допустим, что ф-я какая то внешняя, библиотечная, в которую ничто не натыкаешь. Кроме того, она вызывается периодически.

Думаю, что придётся в поток вынести, т.к. кроме неё ещё могут быть и другие аналогичные, тратящие миллисекунды. Если таких ф-й наберётся достаточно, то ЮИ будет фризиться.

Хотя, конечно, лучше пройтись профилировщиком сначала, а потом думать.  :)

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

а какие сложности использовать QtConcurrent ?
там и поток создается и результат вернется, ничего самому делать не нужно

имхо, выносить в поток или нет зависит от ситуации. Я бы не стал выносить в поток ради антифриза ГУИ и функцию, которая работает 3 сек если она всегда вызывается весьма редко.
С другой стороны, если рассматривать сохранение большого объекта в файл и дальнейшее продолжение работы, то можно в поток передать копию сохраняемого объекта.

В принципе - никаких. Кроме как то что прервать нельзя (вроде как).

kuzulis, прервать можно. У вас поток выполнения будет считывать флаг прерывания и прекращать работу в случае истины, а ГУИ, имея указатель на эту переменную, имеет возможность установить в него значение.

А если ф-я не моя, и не имеет исходников? (если она резолвится?)  ;)
Туда некуда флаг засовывать.


Это гемморой. Там с мьютексами огород нужен и прочее... (как я понял, предлагается QThread::run() ??).
Я как раз хочу от этого избавиться.

Хочу все асинхронно - запустил ф-ю в треде и забыл про нее... когда она отработает - я просто получу уведомление.
Все!

Плохо что прервать нельзя. По крайней мере в доках написано, что QFutureWatcher, полученный от QtConcurrent::run()
не "канселябельный", но вроде как, полученный от мапы "канселябельный"... Надо поизучать этот момент. :)

PS: В рассылке мельком видел предложение, чтобы ввести" платформо-специфичные" вещи для возможности
прерывания потока без всяких флагов: http://lists.qt-project.org/pipermail/development/2016-September/026939.html
(хотя, вроде там не об этом речь)

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

Если вы хотите просто, чтобы интерфейс не застывал, то мьютексы не понадобятся. У вас запись в переменную ведёт только 1 поток, второй же просто считывает её. Для этого не нужны блокировки.

Да, кстати, а QProcess - это вариант! Если и крешнится там что-нить из той ф-ции, то это не проблема.  

Пусть тот процесс висит и ждет команд через пайпы и возвращает результат через пайпы..

Куда понесло? ("пришел за памперсами"  :))

Это хорошо для операций длящихся хотя бы хорошие доли секунды, а иначе - разбазаривание ресурсов, вызов обойдется дороже.

Ну и кто мешает воткнуть qApp->processEvents после того как ф-ция вернула управление? Наверное только неукротимое желание познать "многопоточность"  :)

Имхо, миллисекунды - это ни о чем. Даже если таких функций несколько, и между ними у ГУЯ будет возможность обработать события из очереди, - никаких значимых тормозов.

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