QThread, как с ним работать, где почитать подробно?

[Гурман]

Что грустно-то?

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

я тогда похожую программу написал минут за 30, менее 100 строк, и она работала без проблем и сразу

ладно, проехали... может еще будет все...

Что не заработало с пол-пинка?

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

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

[Авварон]

ни в 1й ОС нельзя работать с гуями не из главного потока, ага?

[pastor]

ни в 1й ОС нельзя работать с гуями не из главного потока, ага?

Неправда, даже в винде можно. Гугл в помощь

[Авварон]

линк плз. Я лично не очень представляю механизм ресайза в таком случае.

[pastor]

Джеффри Рихтер. Создание эффективных WIN32-приложений с учетом специфики 64-разрядной версии Windows (главы 6, 26, 27)

[Гурман]

давайте без оффтопика... но в BeOS легко создавались 2 окна, в которые независимые треды выводили текстовые сообщения, и легко осуществлялся обмен текстовыми сообщениями между тредами через аналоги сигнал-слотов, так, что сообщения отправленные из одного треда, появлялись в окне, связанном с другим

в винде тоже можно, хотя не так изящно, как в BeOS

невозможность делать это в Qt СИЛЬНО ограничивает его применимость

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

[BRE]

давайте без оффтопика... но в BeOS легко создавались 2 окна, в которые независимые треды выводили текстовые сообщения, и легко осуществлялся обмен текстовыми сообщениями между тредами через аналоги сигнал-слотов, так, что сообщения отправленные из одного треда, появлялись в окне, связанном с другим

в винде тоже можно, хотя не так изящно, как в BeOS

невозможность делать это в Qt СИЛЬНО ограничивает его применимость

В Qt это возможно и делается элементарно.

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

В assistant посмотри на QtConcurrent, это Qt.
Посмотри на OpenMP.

[Гурман]

видел, но той изящности и простоты, что была в BeOS, QtConcurent был бы не конкурент

а OpenMP это вообще несколько из другой оперы, хотя еще Тролли могли бы расширить MOC до поддержки мультизадачности на уровне специальных расширений языка

[Гурман]

up...

ну положим, вторая нить приторможена, причем находится в wait( мутекс )

надо в нее передать сигнал, согласно документации, если нить крутится, то для приема сигналов надо запускать ее очередь сообщений exec()

а если нить стоит? насколько обязателен exec()? вижу, что у стоящей нити можно вполне безопасно менять общие глобальные данные (но не хочется этим баловаться, через сигналы правильнее) - а как насчет передачи сигналов именно ОСТАНОВЛЕННОЙ нити?

в общем, оно работает нормально без exec() в данном случае, вопрос скорее в том, насколько запуск обработчика сообщений идеологически обязателен

[Igors]

ну положим, вторая нить приторможена, причем находится в wait( мутекс )

Код:

MyThread thread;
..
thread.wait();

Нитка в которой создался MyThread и которая вызвала wait - будет стоять и никакими сигналами ее не сдвинуть. Однако созданная thread будет выполнять свой run, когда он кончится, вызывающий разблокируется.

Код:

MyThread::run( void )
{
  ..
  mutex.lock();
  ...
  mutex.unlock();
}

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

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

вижу, что у стоящей нити можно вполне безопасно менять общие глобальные данные (но не хочется этим баловаться, через сигналы правильнее)

Ну в принципе для этого мутекс и предназначен (хотя не все так просто как кажется). Посылать остановленной нитке сигнал бессмысленно

[Гурман]

Посылать остановленной нитке сигнал бессмысленно

как оказывается - вовсе нет

ветка остановлена, как в мануале написано:

Код:

	QMutex pausemutex;
	pausemutex.lock();
	paused_condition->wait( &pausemutex );
	pausemutex.unlock();

запускается из метода, находящегося в этом же классе

Код:

	paused_condition->wakeAll();

так вот, сигнал, передаваемый по соединению от главной нити к остановленной, самой остановленной веткой на ура принимается и обрабатывается - причем соединение делается "по-умолчанию", то есть должно быть через очередь

в конце-концов, без запуска цикла сообщений, это же получается всего-навсего вызов функции в остановленной нитке...

[Igors]

так вот, сигнал, передаваемый по соединению от главной нити к остановленной, самой остановленной веткой на ура принимается и обрабатывается - причем соединение делается "по-умолчанию", то есть должно быть через очередь

Без компилябельного примера точно не сказать - но вряд ли. Наверное сигнал был создан с DirectConnection и он действительно выполняется в том смысле что можно напр. звать  методы объекта и.т.п. - но это выполняется в нитке испускающего сигнал.

[Гурман]

Наверное сигнал был создан с DirectConnection и он действительно выполняется

сигнал был создан с соединением по-умолчанию, а вроде как для потомков QThread по-умолчанию соединение создается через очередь

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

но это выполняется в нитке испускающего сигнал

а какая разница, если нить приемника стоит? оно может и через очередь также точно выполняться... мне не важно, в каком треде выполнилась обработка - ведь второй тред все равно стоит внутри paused_condition->wait( &pausemutex ) и ждет, пока его разбудят, а разбудят его совершенно точно после того, как будет обработан принятый сигнал

[Igors]

сигнал был создан с соединением по-умолчанию, а вроде как для потомков QThread по-умолчанию соединение создается через очередь

Зачем "вроде как" если это можно знать точно за пару минут?  Выбор AutoConnection не зависит от QThread или др. конкретного класса. Если оба объекта были созданы в 1 нитке (а значит используют один EventLoop) - то DirectConnection, иначе Queued.

а какая разница, если нить приемника стоит? оно может и через очередь также точно выполняться... мне не важно, в каком треде выполнилась обработка - ведь второй тред все равно стоит внутри paused_condition->wait( &pausemutex ) и ждет, пока его разбудят, а разбудят его совершенно точно после того, как будет обработан принятый сигнал

Ну и хорошо, так делать можно, а нужно ли - от задачи зависит.