Different behaviour between linux and embedded implementation

[tescik]

Hi!

I have an app. stating a thread to do some calculations. This is code to start the thread and to connect the signals between the mainwindow and the thread:


m_calcProc = new BaseCalcProccess();
m_calcProc->moveToThread(&m_thread);

connect(&m_thread, SIGNAL(started()), m_calcProc, SLOT(run()));
connect(m_calcProc, SIGNAL(start()), &m_thread, SLOT(start()));
connect(m_calcProc, SIGNAL(stop()), &m_thread, SLOT(quit()));

m_calcProc->started();


the m_thread is a QThread variable defined in MainWindow

the class BaseCalcProccess is a "public QObject"

and for this class I have the follwing code:


void BaseCalcProccess::started()
{
m_threadData.LoopOn = true;
emit start();
}

void BaseCalcProccess::stopped()
{
m_threadData.LoopOn = false;
emit stop();
usleep(50000);
}

void BaseCalcProccess::run(void )
{
............


the code had been compiled with QtCreator 3.1.1 (based on Qt 5.2.1) and tested in ubuntu 13.10 without any problems!

Then I compiled with Qt 4.8.2 for embedded linux (ARM) and started the application in the target env. and everything is working as expected BUT the "started"-signal is not been triggered or at least, there is no call to the RUN-method for the BaseCalcProccess!!
I had been trying to find some explanations to this behaviour or some way to narrow down the problem without any success, so any advices, suggestions or help is much appreciated!

[wysota]

I'd suggest simplifying your code and making sure signal and slot names are easily distinguishable. Right now it is quite confusing as you have 'start' and 'started' signals and slots everywhere.

If you just have a simple run() function that has fire-and-forget semantics then instead of using QThread and a custom class I suggest to use QRunnable or QtConcurrent::run().

[tescik]

I simplified the code so now I just have one connection between the thread and the mainwindow:


m_calcProc = new BaseCalcProccess();
m_calcProc->moveToThread(&m_thread);
connect(&m_thread, SIGNAL(started()), m_calcProc, SLOT(run()));
m_calcProc->started();


and AGAIN: with QtCreator 3.1.1 (based on Qt 5.2.1) in ubuntu 13.10, works without any problems!
when compiled with Qt 4.8.2 for embedded linux (ARM) is not triggering the run-method!!!!!

[wysota]

In my opinion you should explicitly start the thread first if you really have to complicate your life.

[tescik]

But still the question remains: why it works in one env. but not in the other........
How can I find/narrow down the origin of this behaviour?

[wysota]

But still the question remains: why it works in one env. but not in the other........
How can I find/narrow down the origin of this behaviour?

Probably Qt5 contains some fix or behavior change related to threads and signal handling which isn't present in Qt 4.