Qt: QThread ?

У вас есть шанс перепостить тему пока ещё никто не ответил. На будущее, пользуйтесь пожалуйста кнопкой «Предпросмотр».

MyBase1::MyBase1() {
    MyThread mt;
    // ............
    mt.start();
    // ............
}

И что станет с переменной mt после выхода из конструктора?

> И что станет с переменной mt после выхода из конструктора?

Эт понятно, но я в качестве теста хочу хоть что-то вывести. Например,

mt.start();
sleep(5);

Должно ж HELLO вывести ?

Вот что должно вывести:

$ ./qthreadexample 
QThread: Destroyed while thread is still running
Segmentation fault

А вот рабочий пример:

#include <QCoreApplication>
#include <QThread>
#include <iostream>

class MyThread : public QThread {
   public:
   void run(){ std::cout << "HELLO !!!!" << std::endl; }
};

class MyBase1 {
   MyThread mt;

public:
   MyBase1() {
       mt.start();
   }
};

int main(int argc, char *argv[]) {
    QCoreApplication a(argc, argv);

    MyBase1 mybase;

    return a.exec();
}

Из доков:

Note that deleting a QThread object will not stop the execution of the thread it represents. Deleting a running QThread (i.e. isFinished() returns false) will probably result in a program crash. You can wait() on a thread to make sure that it has finished.

Даже, если так:

class MyBase1 {
  public:
    MyThread *mt;
}

MyBase1::MyBase1() {

   mt = new MyThread();
   ............
   mt->start();
   ............
}

Все равно поток не стартует...

Полный исходный код в студию.

Хм… Всё работает:

#include <Qt>
#include <QCoreApplication>
#include <QThread>
#include <iostream>

class MyThread : public QThread {
public:
	void run(void)
	{
		std::cout << "Hi there!" << std::endl;
	}
};

class MyBase1 {
public:
	MyBase1(void)
	{
		mt = new MyThread();
		mt->start();
	}

	~MyBase1(void)
	{
		mt->wait();
		delete mt;
	}

private:
	MyThread* mt;

};

int main(int argc, char *argv[])
{
	QCoreApplication a(argc, argv);

	MyBase1 mybase;

	return a.exec();
}

А у тебя случаем основной процесс не завершается раньше потока?

есть такая функция в pthread.h, называется pthread_join. Может в Qt есть аналог?

Qt thread не использовал =\

~MyBase1(void) 
      { 
       mt->wait(); 
       delete mt; 
      } 

Да, собственно судя по всему wait в деструкторе тебе и не хватает.

Нет, основной процесс ждет в app.exec().

QThread::wait() будет аналогом pthread_join().

Кстати, без QThread::wait() тоже работает, так как поток быстро завершается, но я предпочитаю безопасный код :-)

wait в деструкторе? это ужасно

Почему?

Деструктурирвоание объекта достаточно специфичная операция. Считаю неуместным выполнения wait в деструкторе, ибо он может быть вызван в самый неожиданный момент

> ов деструкторе, ибо он может быть вызван в самый неожиданный момент

Щито?!?

А ну ка пруф-оф-концепт кода, где деструктор будет вызыван ВНЕЗАПНО, в студию.

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

1. С какого «верху»?

2. Давно ли исключения стали выбрасываться ВНЕЗАПНО?

> Давно ли исключения стали выбрасываться ВНЕЗАПНО?

С момента появления overcommit memory allocation? :-)

Айлолд.

Так чего именно - overcommit memory или memory allocation? Это как бе две разные, почти не связанные друг с другом вещи. ))

ЗЫ. Пальцем в небо. )))

> С какого «верху»?

стека

Давно ли исключения стали выбрасываться ВНЕЗАПНО?

Всегда

> Всегда

Сочувствую.

>> Всегда

Сочувствую.

везде, где нет try/catch исключение будет неожидано

Именно по этому, везде, где нет try/catch их не используют.

К.О.

>Деструктурирвоание объекта достаточно специфичная операция. Считаю неуместным выполнения wait в деструкторе, ибо он может быть вызван в самый неожиданный момент

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

> Именно по этому, везде, где нет try/catch их не используют.

да ладно. в моем коде try/catch встречается внизу цикла обработки сообщений и где нить по середине.

И пишу код так, что любое действие может бросить исключение и все раскрутиться до обработки сообщений. Причем мягко, и ничего не сломается.

Именно это я и имею в виду, говоря что они неожиданны. Я же не знаю, что сосед Вася написал в функции сделайЧтоТоЧтоНадо

overcommit это стратегия выделения памяти (memory allocation). http://www.mjmwired.net/kernel/Documentation/vm/overcommit-accounting

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

Ожидание - это скорее операция завершения, чем деструкурирование. А если кто нить в этот момент попросит из того потока при завершении основной поток? замкнутый цикл.

> любое действие может бросить исключение и все раскрутиться до обработки сообщений. Причем мягко, и ничего не сломается.

Тогда в чем проблема с wait'ом в деструкторе? О_о

> overcommit это

Деточка, мы тут об исключениях разговариваем.

> Тогда в чем проблема с wait'ом в деструкторе? О_о

фактически wait должен дождаться завершения потока. А потом может и зависить от обработки сообщений основного потока. Тогда все -fail

> Ожидание - это скорее операция завершения, чем деструкурирование.

Что мешает одному быть частью другого?

А если кто нить в этот момент попросит из того потока при завершении основной поток?

Думать надо, когда исключения бросаешь. ))

> А потом может и зависить от обработки сообщений основного потока.

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

> Думать надо, когда исключения бросаешь. ))

А вот как раз не надо. Исключение надо бросать всегда при ошибке

> Ну так это проблемы дизайна приложения, не проблемы ожидания потока в деструкторе.

Я считаю что это тоже проблема дизайна. А вот ожидание другого часто не проблема дизайна.

Проблема в том, что исключение будет брошено из другого кода, а не из кода объекта потока

> Исключение надо бросать всегда при ошибке

Если есть гарантия, что его перехватят в корректной точке, иначе - упс.

> Если есть гарантия, что его перехватят в корректной точке, иначе - упс.

Проглатить ошибку себе дороже

> Проблема в том, что исключение будет брошено из другого кода, а не из кода объекта потока

Здесь нет никакой проблемы, если точно известно, что поток завершится. Ну и до кучи хинт: послать сигнал завершения потока можно всё в том же деструкторе, строчкой выше. ;)

> Проглатить ошибку

А я и не предлагал.

Вообще тут вопрос архитектура.

По мне на стеке должен быть объект, которые вызовет завершение потока, а потом сконфигурирует состояние своего потока так, чтоб он работал, как ожидается другим кодом (а не ждал), но при этом учитывал бы, что тот поток завершается

> Вообще тут вопрос архитектура.

Именно.

чтоб он работал, как ожидается другим кодом (а не ждал),

В половине случаев «работа» потока - это ждать.

но при этом учитывал бы, что тот поток завершается

А если без того потока его работа вообще не имеет смысла? Так что вот.

Спор не имеет смысла без конкретного примера. Но я предпочитаю при деструктурировании ничего не делать, кроме как возвращать в состояния (условно говоря) до конструирования

> Спор не имеет смысла без конкретного примера.

Да, так же как и утверждение:

wait в деструкторе? это ужасно

;)

>Что мешает одному быть частью другого?
знаешь такое слово: говнокод?
Деструктор - это всегда освобождение занятых ресурсов, а не ожидание, когда они сами освободятся.

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

короче, когда функция начинает выполнять то, что ей не подразумевается - это типичный антипаттерн.
деструктор в принципе может прервать поток, но никак не ожидать его завершения. это и есть ожидаемое и логичное поведение деструктора.

>И вообще, возьми за привычку читать до конца, а потом уже постить.
возьми привычку не нести чушь не подумав!
и, да, запихни свои советы куда подальше!!

> деструктор в принципе может прервать поток, но никак не ожидать его завершения. это и есть ожидаемое и логичное поведение деструктора.

возьми привычку не нести чушь не подумав!

> любое исключение сверху - неожиданый вызов деструктора

Исключение не должно быть неожиданным. За неожиданные исключения нужно руки отрывать.

> как возвращать в состояния (условно говоря) до конструирования

А там что делается? Только есть нюанс, что при удалении живого потока можно получить segfault. Поэтому если сегфолты не нужны, лучше подожать завершения потока.

> Исключение не должно быть неожиданным. За неожиданные исключения нужно руки отрывать.

Да. Тогда ты должен знать ВЕСЬ код

Дяденька, вы сделайте malloc 16 гигабайт с включенным overcommit, забейте эту память нолями, а потом «разговаривайте об исключениях». Может после этого вы поймете, что исключение действительно может произойти в любой момент времени :-)