Зависание GUI

[mutineer]

Последовательно вряд ли получится - это ж разные потоки и общение между ними идет через eventLoop

[Vladimir]

Если реализовать заполнение структуры в том же потоке, но не данными по сети, то работает все как надо! проблемы начинаются, когда инфа начинает приходить по сети.. может как-то нужно синхронизировать этот процесс??

[Bepec]

Мб минимально компилируемый пример?

[mutineer]

Последовательно вряд ли получится - это ж разные потоки и общение между ними идет через eventLoop

Пардон, скорее всего должен быть прямой вызов, а не через eventLoop

[V1KT0P]

Последовательно вряд ли получится - это ж разные потоки и общение между ними идет через eventLoop

Пардон, скорее всего должен быть прямой вызов, а не через eventLoop

Так из не главного потока в графику лезть нельзя-же или я чего-то не знал? У меня кстати есть похожая ситуация, один поток принимает данные а второй обрабатывает. Так вот раньше было через слоты, я просто создавал новую структуру и указатель на нее через слот посылал второму а уж ее обрабатывал. Но у меня структуры маленькие и их много, а задержка должна быть минимальная, пришлось от слотов отказаться.

[LisandreL]

А получается:
QDebug() << " в потоке сразу после приема данных";
QDebug() << " в слоте отрисовки";
QDebug() << " в слоте отрисовки";
QDebug() << " в слоте отрисовки";
QDebug() << " в слоте отрисовки";

QDebug() << " в потоке сразу после приема данных";
QDebug() << " в потоке сразу после приема данных";
QDebug() << " в слоте отрисовки";

В общем различные комбинации, но не последовательно одна за другой..

Возможно отрисовывать не успеваете с той скоростью, с которой получаете данные (да ещё за счёт глобальной переменной и перетираете одни другими).

Вот так же всё по очереди будет:
connect(tSignReceiv,SIGNAL(onRecvSignal()),indWin,SLOT(slotDrawIndicat()), Qt::BlockingQueuedConnection );

[mutineer]

Последовательно вряд ли получится - это ж разные потоки и общение между ними идет через eventLoop

Пардон, скорее всего должен быть прямой вызов, а не через eventLoop

Так из не главного потока в графику лезть нельзя-же или я чего-то не знал? У меня кстати есть похожая ситуация, один поток принимает данные а второй обрабатывает. Так вот раньше было через слоты, я просто создавал новую структуру и указатель на нее через слот посылал второму а уж ее обрабатывал. Но у меня структуры маленькие и их много, а задержка должна быть минимальная, пришлось от слотов отказаться.

Ну вот если рассужадть логически. Принимающий объект живет в GUI-треде. Отправляющий объект кто? Наследник QThread. По идее он тоже живет в GUI-треде. Значит Qt должен использовать прямой вызов

[V1KT0P]

Ну вот если рассужадть логически. Принимающий объект живет в GUI-треде. Отправляющий объект кто? Наследник QThread. По идее он тоже живет в GUI-треде. Значит Qt должен использовать прямой вызов

Ну так если обработчик слотов треда в главном треде то все что в нем будет выполняться будет тормозить GUI. А он хочет вынести его в отдельный.

[arttr]

Да, да, да, вот в точности такая ситуация была QTcpSocket крутится в отдельном потоке, принимает данные, в этом же потоке происходит их (довольно сложное) преобразование, а потом они эмитятся в ГУИ-поток...головняка на неделю было...

проблему решили так: отказались от переопределения метода run в классе треда. Написали свой класс Thread, в котором был указатель на QThread как приватное поле QThread* thread. Написали слот

Код:

void Thread::start()
{
    thread = new QThread();
    moveToThread(thread);
    thread->moveToThread(thread);

    connect(thread, SIGNAL( started() ),
            this,     SLOT( _threadStarted() ) );


    thread->start();

}

реализовали слот threadStarted(). В этом слоте прописали весь код который должен выполняться в нашем потоке. Так же сделали слот quit (хотя может Вам и метода достаточно будет), к котором разрываем подключение, делаем deleteLater() всем полям класса нашего потока, а потом отстанавливаем поток. Выглятит это примерно так

Код:

    this->deleteLater();
    thread->quit();

Более подробно см. http://labs.qt.nokia.com/2006/12/04/threading-without-the-headache/

Еще про "сеть в отдельном потоке". Cетевые сокеты (QTcpSocket точно) являются асинхронными девайсами, это значит им для нормальной работы нужен работающий цикл обработки событий, а это в свою очередь значит, что создавать/удалять, создавать подключение/разрывать подключение, считывать/записывать нужно в работающем потоке. Поэтому и пришлось делать метод threadStarted.

Теперь структуру Вашу, объявленную extern'ом, если я правильно понял, то она же живет в главном потоке, а заполняется в дочернем данными по сети, еще бы ГУЙ не повис...делайте структуру в своем дочернем потоке и эмитируйте куда хотите...никакие blockingConnection не нужны будут

Дополнение: всем полям класса Thread обязательно делать moveToThread(thread)

[Vladimir]

Вроде выше писали, что moveToThread не есть хорошее решение.. что-то я по ходу жестко тупанул) зачем мне вообще отсылать сигнал, что данные пришли.. в глобальную структуры я эти данные записываю, а когда нужно отрисовать просто считываю! без всякого сигнала.. вроде так и работает! рисуется по данным из сети, но интерфейс всеравно притормаживает.. не так жестко конечно, но есть еще..

[Bepec]

Код в студию! Тогда и тормоза уберём. Причёску сделаем, автомат выдадим и на окопы ЗА РОДИНУУУ!!!!

[arttr]

Вроде выше писали, что moveToThread не есть хорошее решение..

moveToThread - это хорошее решение, если понимать зачем оно нужно.

интерфейс всеравно притормаживает.. не так жестко конечно, но есть еще..

интерфейс и будут замораживаться, именно для этого весь ресурсоемкий код выносят в отдельный поток. Получение данных по сети всяко происходит медленнее, чем отрисовка ГУИ => ГУИ притормаживает

[mutineer]

Вроде выше писали, что moveToThread не есть хорошее решение..

moveToThread хорошее решение, moveToThread(this) нехорошее

[Bepec]

Чем?

mutineer - Если ты точно незнаешь, то не советуй А спор у нас таки пришёл к тому, что это РАВНОПРАВНОЕ решение

[mutineer]

Чем?

mutineer - Если ты точно незнаешь, то не советуй А спор у нас таки пришёл к тому, что это РАВНОПРАВНОЕ решение

Ваш спор пришел к тому, что "я 50 раз запускал, у меня ниче не крешится, так что способ хороший", а с потоками так нельзя. Так что ты тоже точно не знаешь что это нормальное решение