LINUX.ORG.RU

История изменений

Исправление 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...