signal and slot across threads having event loop

[travis]

I have two threads
1) Main GUI Thread
2) A QThread based Thread called DataFetcher

DataFetcher gets data from Systems Message Queue (say a pointer to a C structure). It has to pass the data to Main GUI Thread. Before calling DataFetcher->start() I have established QT::Queued signal and slot connection. However initially I was emiting a pointer to my C structure as parameter in signal
stUIControlAndData *aCtrlNDataPtr = ....;
.....
e.g. emit dataFetchedFromQueue(aCtrlNDataPtr)

I read the QT doc and stuff it says
To quote from qt documentation

"With queued connections, the parameters must be of types that are known to Qt's meta-object system, because Qt needs to copy the arguments to store them in an event behind the scenes. If you try to use a queued connection and get the error message QObject::connect: Cannot queue arguments of type 'MyType' call qRegisterMetaType() to register the data type before you establish the connection."

Source: http://doc.trolltech.com/4.2/qt.html...ctionType-enum

Any class or struct that has a public constructor, a public copy constructor, and a public destructor can be registered."
http://doc.trolltech.com/4.2/qmetaty...gisterMetaType

So passing pointer (stUIControlAndData*) seems wrong.

Am I thinking on the right lines. There are arbitary crash with my app, stack trace always goes into GUI and into QT calls which inturn leads in malloc (libc).

I also what to say I changes the who design and code to pass GUI C++ based class that corresponds to (stUIControlAndData). I am not passing pointers anymore. Create on the stack of DataFetcher Thread and pass it to GUI Main Thread.

I wish I could just post the code and make my life easier. However thats not an option.

Bottomline: I am trying to debug the app which crashes shows QT stack trace. I suspect that may be the way data is passed between the two GUI Threads has some problem.

[jacek]

So passing pointer (stUIControlAndData*) seems wrong.

No, there's nothing wrong with passing pointers through a queued connection, but you have to pass the ownership as well.

between the two GUI Threads

What do you mean by "two GUI threads"?

Do you make any connections between QThread subclasses and other objects?

[travis]

"What do you mean by "two GUI threads"?"

One QThread subclass , and other the QApplication based Main Thread.

"Do you make any connections between QThread subclasses and other objects?"

Yes, I make connections with QObject subclass that resides in Main Thread (as in Thread affinity) and was also created in Main Thread.

[jacek]

One QThread subclass , and other the QApplication based Main Thread.

Does this QThread subclass have anything to do with GUI?

Yes, I make connections with QObject subclass that resides in Main Thread (as in Thread affinity) and was also created in Main Thread.

Does this QObject subclass send signals to the thread?

[mclark]

Originally Posted by jacek
...but you have to pass the ownership as well.

Jacek, what do you mean by this?

Unless the pointer is const, cannot the slot alter the data pointed at, or even delete the pointer?

[jacek]

Jacek, what do you mean by this?

If you pass a pointer to another thread, it should become responsible for deleting it and the sender thread shouldn't have any access to that object anymore (unless you use proper locking mechanisms). You don't want any race conditions.

[mclark]

Thanks jacek, I thought maybe there was some implicit Qt way to guarantee the ownership swap. But, I see you mean this is the responsibility of the programmer.

BTW, thanks for the quick reply!