ситуация следующая.

Есть QMainWidow у которого есть потоковый метод. Он крутиться по флагу, вычитывает данные и посылает событие.

void QMainWindow::start()
{
    ...
    m_stopped = false;
    thread->start();
    ...
}
void QMainWindow::stop()
{
    ...
    m_stopped = true;
    thread->wait();
    ...
}

void QMainWindow::execute()
{
    while (!m_stopped)
    {
        // read data
        QCoreApplication::postEvent(new MyEvent(mydata));
    }
}

так вот иногда происходит висяк. Преположение в том, что customEvent для QMainWindow
работает в первичном потоке и stop() тоже работает в первичном потоке.

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

Может ли в данном случае быть deadlock или postEvent отработает всегда ?
Если так, то где может быть висяк и как его разрулить ?

Что-то я не соображу, где "первичный" поток, а где "вторичный"?
Что написано в методе run "вторичного" потока, как и где вызывается QMainWindow::execute()?

Висяк из-за того, что ты "захламляешь" очередь событий.

    while (!m_stopped)
    {
        // read data
        QCoreApplication::postEvent(new MyEvent(mydata));
    }

Тут в любом случае sleep()'a не хватает.

не - sleep есть (код не целиком)
более того - выполнение события ожидается через QMutex/QWaitCondition

Не факт, может чтение раз в секунду происходит.


Возможно, он процессорное время на mutex'ах отдает, внутри чтения данных.

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

void QMainWindow::stop()
{
    ...
    m_stopped = true;
    thread->wait();
    ...
}

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



Я ведь правильно понимаю, гуй висит?

Сообщение отредактировал SABROG - 24.6.2009, 16:09

ладно - тогда подробнее

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

Пример

void stop()
{
   stopThread->start();
   stopThread->wait();
}
void funcStopThread ()
{
    m_stopped = true;
    readThread->wait();
}
void readThread()
{
    while(!m_stopped)
    {
        // read data
        QCoreApplication::postEvent(...);
        Sleep(1000);
    }
}

В итоге у тебя 3 потока: основной, читающий с устройства и поток, который ждет завершения потока считывающего с устройства. Тогда ждать завершения надо в run() второго потока. Но это странно.

А для чего такие сложности со вторым останавливающим потоком?

Как мне кажется, тебе нужно сокращать время отклика потока для чтения, т.е. ты флаг остановки установил, этот поток должен завершиться как можно быстрее. Тогда и wait будет отрабатывать быстро, или не использовать wait, а ждать от потока сигнал finised? Тут от твоей задачи зависит.

void readThread()
{
    for(;;)
    {
        if( m_stopped )
            break;
        // read data

        if( m_stopped )
            break;
        QCoreApplication::postEvent(...);

        if( m_stopped )
            break;
        Sleep(1000);
    }
}

Да, на sleep(1000) будет секундная задержка проверки флага. Здесь нужно что то придумать.

Сообщение отредактировал BRE - 24.6.2009, 16:33

второго - это какого ? и чем странно то...


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