The drawback of signal/slots ?

VincentLiu

@VRonin Sorry that I didn't check the code snippet. The real one is just what you displayed. But the error message still says that I should register the type "Mat&". Any else is important?

VRonin

This is strange, could you post the entire error?

VincentLiu

@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 ?

VRonin

if vector is std::vector then it's because it's not natively supported by QVariant (i.e. you have to register the vector with the meta object system) alternatively you can use QVector which is already supported

stryga42

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.

vladstelmahovsky

@VRonin in case of Qt:QueuedConnection is will be passed by value anyway

VRonin

@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

kshegunov

@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

@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?

kshegunov

@VincentLiu @stryga42

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).

VincentLiu

@kshegunov

Thanks. Actually I did what you displayed, but it works until I use Qt:DirectConnection.

kshegunov

@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

@kshegunov Really !!! Thanks, I'll try it