Thread и ProgressBar в QT

[bigirbis]

А если достаточно большие блоки данных идут или сеть хреновая? Все приложение подвиснет?

[Alex03]

QApplication::postEvent( someDialog, new QHideEvent );

А GUI-ями из левых потоков рулить вообще ИМХО не правильно.
Где гарантия что someDialog - всё ещё валидный указатель? Понятно что можно и это гарантировать, но ....
Т.е. если есть поток занимающийся некой передачей данных по сети, то и пусть сигналит (теми же postEvent()) о том что данные переданны на Х процентов, или там что ошибочка вышла.
А уж GUI поток пусть решает чё ему нарисовать иль скрыть.

добавлено спустя 18 минут:

 

А если достаточно большие блоки данных идут или сеть хреновая? Все приложение подвиснет?

Нет не подвиснет.
Т.е. много и за раз Вы не передадите/не примите,  writeBlock() возьмёт сколько надо ( зависит от ОС, а м.б. и от qt-внутренних буферов) и эту цифирь Вам же и вернёт.
Кстати системные вызовы ОС поступают точно также.

Впрочем при большом трафике можно уже на нехватку ресурсов нарваться.

Для примера я принимал по сети и отрисовывал ч/б картинку ~692х520  (361920байт) с частотой 7.5 кадра в сек (2714400 байт/сек).
При этом если тормоза и наблюдались на некоторых машинках то не в коде работы с сетью, а в коде преобразования из QImage в QPixmip и отрисовку bitBlt() (В потомке ScrollView), но это уже отдельная песня.
Всё это было несколько лет назад и под линуксом.

[mhalionn]

Да ты прав тысячи чертей. Продаю свои руки и ухожу в монастырь завтра. Спасибо за помощь я понял свою непровату.

[Dendy]

Alex03, тьІ абсолютно прав.

СокетьІ в Qt3/Qt4 изначально неблокирующие, то-есть их использование из главного потока вполне оправдано, если нужно использовать конечное количество соединений и не на полную загрузку сети/проца.

Работу с сетью в другой поток/потоки следует вьІносить в случаях:

1. Если вьІ используете N соединений, где N - число произвольное и меняется на лету (типа клиент Jabber'а, броузер, али сервер какой-нить).

2. Если вьІ используете сеть на полную загрузку. То-есть отправляете данньІе сразу же как только возможно и принимаете сразу же как только пришли. Если вам нужно забить канал по максимуму. Возможно при етом вьІ почувствуете удар по перфомансу GUI-приложений, так как работа в преобразованием данньІх займёт львиную долю итерации главного цикла.

[SLiDER]

при етом вьІ почувствуете удар по перфомансу

Вау, это наверное больно. В аналы, адназначна.      

[Hordi]

"асинхронный" - это НЕ синоним "неблокируемый"

[Alex03]

"асинхронный" - это НЕ синоним "неблокируемый"

Синоним, не синоним, это к русскому языку.
Какой по Вашему из этих терминов не применим к QSocket?

ИМХО оба термина вполне употребимы к QSocket.

При желании конечно можно пользоваться и блокирующими функциями типа QSocket::waitFor...(), он это уже отдельная песня.

[sh]

похожая ситуация

Xlib: unexpected async reply (sequence 0x60fa9)!


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

[SLiDER]

похожая ситуация

Xlib: unexpected async reply (sequence 0x60fa9)!


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

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

[Sergeich]

В третьей куте нельзя использовать механизм сигналов / слотов между разными потоками. Пользуй postEvent

[sh]

В третьей куте нельзя использовать механизм сигналов / слотов между разными потоками. Пользуй postEvent

спасибо за ответ
тогда нужно будет инициализировать дочерние потоки указателем на родительский в очередь которого скидывать сообщения, думаю в слотах обойдусь QMutex'ом

забил на qmutex, сделал через postEvent с qcustomevent

[Sergeich]

В дочерние потоки нужно передавать указатель на объект, к-ый будет обрабатывать сообщения от потока. Никаких мьютексов при этом использовать не надо, postEvent - thread-safe метод. Код должен выглядеть приблизительно так:
Определяем событие

Код:

class ProgressEvent : public QEvent
{
public:
  enum { TypeId = QEvent::User + 1001 };
  ProgressEvent( const QString& operation, int progress ) 
     : QEvent( ProgressEvent::TypeId ), opname(QDeepCopy<QString> (operation) ), prgs(progress) {}
  QString operation() const { return opname; }
  int progress() const { return prgs; }
private:
  QString opname;
  int prgs; 
};

Посылаем событие из дочернего потока

Код:

QString opname = "Initializing";
int prgs = 50;
QApplication::postEvent( receiver, new ProgressEvent( opname, prgs ) );

Обрабатываем полученное событие

Код:

bool Receiver::event( QEvent* e )
{
  if ( e->type() ==  ProgressEvent::TypeId ) {
    ProgressEvent* pe = (ProgressEvent*) e;
    progressDialog->setLabelText( pe->operation() );
    progressDialog->setProgress( pe->progress() );
    return true;
  }
  return false;
}

[Примерный ученик]

Sergeich Респект...
Очень толковый примерчик...
Работает как швейцарские часы

[SABROG]

Sergeich Респект...
Очень толковый примерчик...
Работает как швейцарские часы

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

[Примерный ученик]

В QT3.3.8 он очень и очень ничего