Прошу объяснения так сказать на пальцах, в чем разница

Плюсы, минусы, я пока особой разницы не вижу, ну только кроме разных вызовов и использования.

Ну это я тоже заметил, но думал может есть какие то существенные отличия, насколько я понимаю QtConcurrent подходит для небольших вещей, и насколько я понимаю с ним нереально использовать всю силу сигнало\слотовой модели.

У QtConcurrent есть механизм паралельных вычислений.

Также скорость QtConcurrent заметно падает если одни из задач массива требуют значительно больше времени чем другие. Это еще называется "гранулярностью".

Достаточно унаследоваться от QObject'a и передать адрес на метод твоего класса вместо адреса обычной Си функции. Я именно так реализовал работу сигналов и слотов в своем потоке, который запускал через QtConcurrent::run().


QThread::currentThread() статический метод, который используется в нескольких Qtшных примерах для демонстрации возможностей QtConcurrent, поэтому такое должно работать:

C++ (Qt)
QThread::currentThread()->setPriority(QThread::LowestPriority);
 

Судя по исходникам QThread - currentThread() динамически вызывает API GetCurrentThread() под Win32. И метод setPriority() вызывает SetThreadPriority(). По логике всё должно работать.

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

>Нет, это не так.
Что значит не так?
Вот код:

C++ (Qt)
//...
QThread::currentThread()->setPriority(QThread::LowestPriority);
//...
 

текущий поток, в котором приведён этот код, будет подвергнут изменению приоритета

>QtConcurrent выполняет этот код
он вообще к этому коду отношения не имеет.

Но теперь я понял что имел в виду SABROG. Он имел в виду - воткнуть эту строку в функцию, которая передаётся в QtConcurrent.