The drawback of signal/slots ?
-
Hi all, do you really think that passing by reference is fine for an asynchronous signal? Both sender and receiver could change the content but with undefined sequence. My guess is that Qt refuses to pass the reference if it is going to use an asyc signal, as it is the default for thread-spanning signals.
Synchronous signals are more or less simple function calls, so there it would be OK.
I guess this is also the major reason why Qt does not support return values in the signal/slot system. -
@VincentLiu No, but just because the syntax is wrong. you declare the signal with:
signals: void AtoBSignal(Mat& mat);and emit it with:
Mat mat; // do something with mat emit AtoBSignal(mat);P.S.
if you do not wish to edit the original object inside the slot (as is normally the case) useconst Mat& matinstead ofMat& matfor safety@VRonin in case of Qt:QueuedConnection is will be passed by value anyway
-
Hi all, do you really think that passing by reference is fine for an asynchronous signal? Both sender and receiver could change the content but with undefined sequence. My guess is that Qt refuses to pass the reference if it is going to use an asyc signal, as it is the default for thread-spanning signals.
Synchronous signals are more or less simple function calls, so there it would be OK.
I guess this is also the major reason why Qt does not support return values in the signal/slot system.@stryga42 said in The drawback of signal/slots ?:
Both sender and receiver could change the content
If 2 threads are accessing on read/write the same variable you have to handle it manually, set up a mutex of some sort. It's not as easy as passing a reference
-
Hi all, do you really think that passing by reference is fine for an asynchronous signal? Both sender and receiver could change the content but with undefined sequence. My guess is that Qt refuses to pass the reference if it is going to use an asyc signal, as it is the default for thread-spanning signals.
Synchronous signals are more or less simple function calls, so there it would be OK.
I guess this is also the major reason why Qt does not support return values in the signal/slot system.@stryga42 said in The drawback of signal/slots ?:
Hi all, do you really think that passing by reference is fine for an asynchronous signal?
It is fine because you get a reference to a copy of the original object (hence the need to do
qRegisterMetaType<>().Both sender and receiver could change the content but with undefined sequence.
Only with direct connections, which isn't the default accross threads.
My guess is that Qt refuses to pass the reference if it is going to use an asyc signal, as it is the default for thread-spanning signals.
No. You must register the type with the meta-type system, so Qt knows how to copy it when the slot-invocation event is placed in the receiving thread's event loop.
Synchronous signals are more or less simple function calls, so there it would be OK.
It wouldn't because you need to guard the reference manually from both threads.
I guess this is also the major reason why Qt does not support return values in the signal/slot system.
The major reason is because when queuing a slot for execution (as with default signal-slot connection across threads) there's no meaning to return values. You can't know when the slot will be invoked, and even if you could you will already have far surpassed the point where you can obtain a return value in the emitting thread.
-
@stryga42 said in The drawback of signal/slots ?:
Hi all, do you really think that passing by reference is fine for an asynchronous signal?
It is fine because you get a reference to a copy of the original object (hence the need to do
qRegisterMetaType<>().Both sender and receiver could change the content but with undefined sequence.
Only with direct connections, which isn't the default accross threads.
My guess is that Qt refuses to pass the reference if it is going to use an asyc signal, as it is the default for thread-spanning signals.
No. You must register the type with the meta-type system, so Qt knows how to copy it when the slot-invocation event is placed in the receiving thread's event loop.
Synchronous signals are more or less simple function calls, so there it would be OK.
It wouldn't because you need to guard the reference manually from both threads.
I guess this is also the major reason why Qt does not support return values in the signal/slot system.
The major reason is because when queuing a slot for execution (as with default signal-slot connection across threads) there's no meaning to return values. You can't know when the slot will be invoked, and even if you could you will already have far surpassed the point where you can obtain a return value in the emitting thread.
@kshegunov
Sure, return values for queued connection are quite useless., I tried to say that.
But the original question is then still open; maybe the class Mat has no copy constructor available? -
@VRonin Hi, below is the signal and slot:
void bgVecReadySignal(vector<Mat>& bgVec); void bgVecReadySlot(vector<Mat>& bgVec);And in main.cpp:
int main(int argc, char *argv[]) { qDebug() << "Invoked main.cpp - " << QThread::currentThreadId(); qRegisterMetaType<vector<Mat>>("vector<Mat>"); qRegisterMetaType<Mat>("Mat"); ..... }And error message shows:
QObject::connect: Cannot queue arguments of type 'vector<Mat>&' (Make sure 'vector<Mat>&' is registered using qRegisterMetaType().)Did I miss anything? Thanks
I just found that using Qt::DirectConnection works fine. However, is it a right way to do so ?
qRegisterMetaType<Mat>(); qRegisterMetaType<vector<Mat>>();should fix it, provided there's also:
Q_DECLARE_METATYPE(Mat) Q_DECLARE_METATYPE(vector<Mat>)somewhere in the header(s).
-
qRegisterMetaType<Mat>(); qRegisterMetaType<vector<Mat>>();should fix it, provided there's also:
Q_DECLARE_METATYPE(Mat) Q_DECLARE_METATYPE(vector<Mat>)somewhere in the header(s).
Thanks. Actually I did what you displayed, but it works until I use Qt:DirectConnection.
-
Thanks. Actually I did what you displayed, but it works until I use Qt:DirectConnection.
@VincentLiu said in The drawback of signal/slots ?:
Actually I did what you displayed
Not according to the snippet you posted. Bear in mind:
qRegisterMetaType<Mat>();and
qRegisterMetaType<Mat>("Mat");are different things in principle.
-
@VincentLiu said in The drawback of signal/slots ?:
Actually I did what you displayed
Not according to the snippet you posted. Bear in mind:
qRegisterMetaType<Mat>();and
qRegisterMetaType<Mat>("Mat");are different things in principle.
@kshegunov Really !!! Thanks, I'll try it
