[Qt-interest] Event-Loop Threading start and communication issue

[BRM]

Okay - for the record (and those reading archives) - this came down to a simple issue of 'put it in the constructor' versus use a Signal/Slot.
Unless there is some specific function in place to detect that a thread is running with its event loop, the below just won't work.

Ben



----- Original Message ----
From: BRM <bm_witness at yahoo.com>
To: qt-interest <qt-interest at trolltech.com>
Sent: Thu, December 10, 2009 5:18:42 PM
Subject: [Qt-interest] Event-Loop Threading start and communication issue

I have an issue which I think comes down to timing, specifically when a thread starts, executes its run(), and gets the whole event loop running.
On one system, the software works perfectly fine; but when I move it to another system it fails as I describe below.

Note: This is all with Qt 4.5.1 Embedded with QtService under Linux 2.6.18; gcc/g++ defaults to i486.

The basic logic is:
- some event happens, receive a signal with object A in the main thread to a slot
- create a thread to handle A for the duration A exists
- setup the signals/slots
- start the thread (thread->start()) and save the thread instance
- provide A to the thread in some manner[1]
- thread A signals back to the main thread that it received A and is ready to go

I've tried providing 'A' to the thread in two manners:
i) Emit A to the thread near immediately after starting it:

     ...
        thread->start();
     Q_EMIT sendAtoThread(A);
     ... 

ii) buffer A, and connect a slot to the thread's started() signal, and then Emit A to the thread from the slot:
     ...
     buffer(A);
     connect(thread,SIGNAL(started()),this,SLOT(someSlot()));
     thread->start();
     ...
mainThread::someSlot()
{
  Q_EMIT sendAtoThread(a);
}

However, in neither of these cases does it seem to work on the system in question. The Thread never sends the signal back to the main thread that it got A.
I verified this by setting up some introspection with a number QSignalSpy instance, both in the main thread, and in the thread itself.
When the program exists (and the thread exists) it dumps a list of the registered QSignalSpy objects and the count.
>From this, I can see the following:

The signal from where A is originally generated happen.
The thread signals when it started (so 'ii' is possible).
The main thread sends A to the thread.

However, the thread never sees the signal from the main thread for sending A to it.

Note: The thread runs is own event loop. It's run() is basically:
- allocate an object
- connect the signal
- exec()
- de-allocate the object

The other perplexing side of this is that I see a similar behavior when
I run it under the debugger (gdb); but then things work if I set a
breakpoint;
which makes me think this is a timing issue of some sort, likely with starting the thread.

I'm pretty sure this is a thread communications issue; but not entirely sure where to go from here as far as debugging.

What's the correct way for determine when a thread has started from the creating thread?
I also tried a variant of 'i' above where I did the following between the two listed steps:

while (threadPointer.isNull() == false && threadPointer->isRunning() == false);

But that didn't resolve the issue. I thought I had seem some Qt functions for waiting on threads to do start/stop, but I can't locate them at the moment.

I'm not sure I can upgrade to Qt 4.5.3 or Qt 4.6 at the moment; but will make that transition at some point.
(If there is a big reason to do so I could probably push it through; but I'd have to have a very good reason.)

Has anyone seen this kind of behavior before? If so, how did you trace the issue? If possible, what was the issue?

Tips are very well appreciated.

Ben

_______________________________________________
Qt-interest mailing list
Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest