История изменений
Исправление I-Love-Microsoft, (текущая версия) :
Когда я не умел работать с QThread как ты сейчас, я тоже страдал... :) И зачем делать эти коннекты обязательно в run, и зачем вообще там Qt::QueuedConnection?
Смотри, я сейчас напишу как я это представляю, а другие ЛОРовцы подтвердят или опровергнут мои слова.
В основном потоке:
QThread shit_thread; // в header-е
shit_object so;
...
// далее в основном коде:
shit_thread.start();
so.moveToThread(&shit_thread);
Сам объект:
class shit_object : public QObject
{
Q_OBJECT
...
signals:
slots:
Внутри shit_object делаешь обычные коннекты как всегда делал. Представь что shit_object это вообще обычный кусок Qt-шной программы. И всего лишь эти две строки shit_thread.start(); so.moveToThread(&shit_thread); сделают чтобы целый отдельный кусок кода, этот объект - работал в отдельном потоке. А между основными потоком и этим объектом можешь безопасно обмениваться сигналами-слотами.
Есть известная статья на эту тему, просто там гораздо сложнее описали подход, который я сейчас применяю: http://habrahabr.ru/post/150274/
т.е. фактически, объект работает в отдельном потоке с отдельным циклом обработки сообщения (который не блокирует и не мешает основному потоку) просто при помощи тупо moveToThread... И никаких там run, никаких страданий, никаких мьютексов если только сигналы-слоты, а слоты вызываются при помощи invokeMethod или просто отсылки сигналов из основного потока...
Исправление I-Love-Microsoft, :
Когда я не умел работать с QThread как ты сейчас, я тоже страдал... :) И зачем делать эти коннекты обязательно в run, и зачем вообще там Qt::QueuedConnection?
Смотри, я сейчас напишу как я это представляю, а другие ЛОРовцы подтвердят или опровергнут мои слова.
В основном потоке:
QThread shit_thread; // в header-е
shit_object so;
...
// далее в основном коде:
shit_thread.start();
so.moveToThread(&shit_thread);
Сам объект:
class shit_object : public QObject
{
Q_OBJECT
...
signals:
slots:
Внутри shit_object делаешь обычные коннекты как всегда делал. Представь что shit_object это вообще обычный кусок Qt-шной программы. И всего лишь эти две строки shit_thread.start(); so.moveToThread(&shit_thread); сделают чтобы целый отдельный кусок кода, этот объект - работал в отдельном потоке. А между основными потоком и этим объектом можешь безопасно обмениваться сигналами-слотами.
Есть известная статья на эту тему, просто там гораздо сложнее описали подход, который я сейчас применяю: http://habrahabr.ru/post/150274/
т.е. фактически, объект работает в отдельном потоке с отдельным циклом обработки сообщения (который не блокирует и не мешает основному потоку) просто при помощи тупо moveToThread... И никаких там run, никаких страданий...
Исходная версия I-Love-Microsoft, :
Когда я не умел работать с QThread как ты сейчас, я тоже страдал... :) И зачем делать эти коннекты обязательно в run, и зачем вообще там Qt::QueuedConnection?
Смотри, я сейчас напишу как я это представляю, а другие ЛОРовцы подтвердят или опровергнут мои слова.
В основном потоке:
QThread shit_thread; // в header-е
shit_object so;
...
// далее в основном коде:
shit_thread.start();
so.moveToThread(&shit_thread);
Сам объект:
class shit_object : public QObject
{
Q_OBJECT
...
signals:
slots:
Внутри shit_object делаешь обычные коннекты как всегда делал. Представь что shit_object это вообще обычный кусок Qt-шной программы. И всего лишь эти две строки shit_thread.start(); so.moveToThread(&shit_thread); сделают чтобы целый отдельный кусок кода, этот объект - работал в отдельном потоке. А между основными потоком и этим объектом можешь безопасно обмениваться сигналами-слотами.
Есть известная статья на эту тему, просто там гораздо сложнее описали подход, который я сейчас применяю: http://habrahabr.ru/post/150274/
т.е. фактически, объект работает в отдельном потоке с отдельным циклом обработки сообщения (который не блокирует и не мешает основному потоку) просто при помощи тупо moveToThread...