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

[BRE]

как всетаки поток запускается? thread->run()?

processThread()->run();

Смотри что происходит при этом:
Вызывается метод run в главном потоке;
Вызывается start, при этом создается новый поток в котором начинает выполняться метод run;
После отработки start продолжает выполняться run в главном потоке (DataProcessor->Process());
Выполняется DataProcessor->Process() в дочернем потоке.

Поэтому у тебя GUI и останавливается.

[Гурман]

После отработки start продолжает выполняться run в главном потоке (DataProcessor->Process())

по коду в главном потоке вызова DataProcessor->Process() не должно происходить, поскольку start у меня рекурсивно вызывал run, сам повторно не выполнялся, так как уже выполнился, и только после этого начинал выполняться Process()

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

[BRE]

по коду в главном потоке вызова DataProcessor->Process() не должно происходить, поскольку start у меня рекурсивно вызывал run, сам повторно не выполнялся, так как уже выполнился, и только после этого начинал выполняться Process()

start создает контекст дочерней нити и в нем заново запускает run. В контексте дочернего потока start сразу выходит и запускает Process, но в главном потоке управление получает следующая строка после start и соответственно запускается свой Process.

[Гурман]

да, так и есть Process() запускался дважды

заработало, но только с Qt::BlockingQueuedConnection, если просто Qt::QueuedConnection то интерфейс все равно не работает, хотя строки выводятся

теперь такой вопрос: QThread::isRunning () is thread-safe? можно его вызывать из главной нити, чтобы определить выполняется вторая, или уже завершилась?

[BRE]

заработало, но только с Qt::BlockingQueuedConnection, если просто Qt::QueuedConnection то интерфейс все равно не работает, хотя строки выводятся

Покажи побольше кода.
Тяжело телепатировать. 

[Гурман]

Покажи побольше кода.

какого? всего? десятки тысяч строк...

- убрал вызов start() внутри run()
- заменил вызов run() на start() в главной нити
- убрал комментарии при соединении объектов, получилось

Код:

	connect( this, SIGNAL(sigConsoleMessage(QString)), pMainWindow, SLOT(slMessage(QString)), Qt::QueuedConnection);

работает почти правильно, порождается один процесс обработки (вчера точно было 2, я видел вывод обоих, и не понимал, откуда берется второй), но интерфейс блокирован, заменяю на Qt::BlockingQueuedConnection - все работает

[BRE]

Нее, весь не надо...

Покажи что за объект DataProcessor, как описан его класс, как он создается, хотя бы примерно что находиться в методе Process, где вызывается thread_stream?

[Гурман]

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

Код:

bool SomeClass::Process()
{
    // здесь сначала некоторые проверки значений полей класса SomeClass, никаких внешних обращений
    return execute( FALSE );  // это функция на С
}

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

далее в объекте класса SomeClass, в его методах, в библиотеке на С, никакие классы Qt не вызываются и не используются, гарантированно, этот класс и дальнейшая обработка ранее отлажены без использования Qt, единственная связь с Qt только в выдаче сообщений во время работы второй нити, она через функцию-хук thread_stream( char* msg )

на самом деле, перед выполнением , заменяется точка входа в функцию выдачи сообщений, которую вызывает С-библиотека, потом она восстанавливается

Код:

void ProcessThread::run()
{
	messasge_function = thread_stream; // ее код был ранее
        DataProcessor->Process();
	messasge_function = print_stream;
}

где message_function глобальный extern "C" указатель на функцию, print_stream - указатель на функцию, которая производит выдачу сообщений, когда вторая нить не активна

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

возможно есть смысл вызывать extern "C" int execute() прямо из run(), правда тогда придется продублировать поля из SomeClass, поскольку организовывать его взаимодействие с ProcessThread никак нельзя, SomeClass должен остаться Qt-независимым

[BRE]

К объекту DataProcessor кто-то еще обращается из главного потока?
Какие-то объекты синхронизации используются?

[Гурман]

К объекту DataProcessor кто-то еще обращается из главного потока?

нет

Какие-то объекты синхронизации используются?

нет

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

[Авварон]

а разве чтобы нормально работали сигналы\слоты в треде, вызов exec() не нужен?
моё имхо - надо run вообще не переобпределять, сделать слот calc() и его из мейна дергать через InvokeMathod с QueuedConnection когда надо запстить расчеты. А start() нити звать в конструкторе оной к примеру

[BRE]

а разве чтобы нормально работали сигналы\слоты в треде, вызов exec() не нужен?

Для отсылки сигнала - нет, а вот для получения и вызова слота - нужен.

[Авварон]

ааа, ясно, спасибо.

[Гурман]

работает пока с Blocking, потом придется вернуться, и разобраться почему просто очередь не работает, но как-то все это грустно... 

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

[Igors]

Код:

	connect( this, SIGNAL(sigConsoleMessage(QString)), pMainWindow, SLOT(slMessage(QString)), Qt::QueuedConnection);

работает почти правильно, порождается один процесс обработки (вчера точно было 2, я видел вывод обоих, и не понимал, откуда берется второй), но интерфейс блокирован, заменяю на Qt::BlockingQueuedConnection - все работает

Разберитесь в каких нитках были созданы сигнал/слот (this и pMainWindow). В сложной программе проще это напечатать в консоль. Если BlockingQueuedConnection вообще работает - они были созданы в разных.

работает пока с Blocking, потом придется вернуться, и разобраться почему просто очередь не работает, но как-то все это грустно... 

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

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

Никто не мешает читать и вызывать методы объектов созданных в др. нитках, они должны быть thread-safe - в Qt и везде. Про мутексы и семафоры вспомнить придется если пишете/читаете в разных нитках. Горести по поводу отсутствия какого-то "особенного" сервиса у Qt лишены оснований поскольку все эти вещи/понятия общие для multi-threading и для любого OC и любая библиотека может только сделать это более удобным.