> From: Bo Thorsen <[email protected]> >Den 28-08-2012 04:10, Preet skrev: >> Hiya, >> >> I have a project where I'm trying to asynchronously reply to a signal. >> So if ObjectA sends ObjectB a signal, ObjectB will send ObjectA a >> reply signal at some later point in time. ObjectA is guaranteed to be >> alive when ObjectB decides to send a reply. ObjectAs and ObjectB also >> live in different QThreads. ObjectB doesn't know about ObjectA in >> advance, so I use QObject::sender() to store ObjectA's pointer in a >> queue for when ObjectB is ready to reply. There are many such >> "ObjectA"s out there that ObjectB can reply to. >> >> I see three ways to implement this in an application: >> >> When ObjectB is ready to reply, >> 1 have it connect to the right ObjectA, emit a signal, then disconnect. >> 2 use QMetaObject::invoke() to invoke the right ObjectA's corresponding slot >> 3 be connected to all ObjectA's and just emit a signal with the >> QObject sender pointer; this way the ObjectAs can filter out which >> signals are for them in the slot itself >> >> I'd like to know what the best method is in terms of speed/minimal >> complexity, or if there's a better method I haven't listed. ObjectB >> may be required to send hundreds of replies every second, so speed is >> important. 3 seems like its the worst, since every reply will invoke >> multiple slots. 1 and 2 seem similar; I'm kind of concerned about >> calling "connect" and "disconnect" so often in 1. > >The third is the worst, if you have a bunch of ObjectA's. If you only >have a couple of them, this is by far the best. Because this also means >you don't have to worry about whether the object has been deleted since >it emitted the signal. > >The first actually uses the second, because those are cross thread >signal slot connections. But by using the connect, you will >automatically get the call moved across to the other thread. If you use >invoke, you don't get this. If it's okay to call across threads, invoke >is the fastest. > >You have to figure out how to make sure the ObjectA still exists at the >point where ObjectB wants to call it. This is the part that really >worries me with the situation you have described here. > >Instead of doing this, I'd probably implement some kind of multiplexer >object that sits between the two threads and handles all the >communication and knows the lifetime of both ObjectA and ObjectB. >Whether you would want one big object that handles all of them, or >create a connection object for each connect, that's up to you. >
I had a similar situation where I had an inverse of QSignalMapper - I had a signal with a QByteArray for data and a uint32_t "key". Only receives with the same "key" were to get the data. The senders, multiplexer, and receives were all in their own threads. Now, the nice thing about #2 is that QMetaMethod::invoke()'s second argument[1] is the same as the last argument in QObject::connect(). Would it not be wrong to say that that handles the movement across the threads for you then? It's worked very well for me at least. http://doc.qt.nokia.com/4.7-snapshot/qmetamethod.html#invoke Ben _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
