[Qt-interest] Synchronous signals, is that possible?

[Andreas Pakulat]

On 15.02.09 14:28:51, Andrea Franceschini wrote:
> Hello everybody,
> I'm facing a little dilemma about elegance and pointers. I have a
> class which at some time takes a pointer to an object. I can obviously
> take that pointer and do the dirty work inside this class but instead
> I decided to make a proxy/adapter layer that takes those pointers and
> emits them as signals carrying them as parameters, to which the rest
> of my application connects.
> The thing I didn't know in advance is that the original developer of
> the underlaying system assumed that all this process was synchronous,
> so he calls the takeThis(Pointer*) method of a bunch of listeners and
> assumes that when every single call returned, it was time to delete
> the pointer. Unfortunately this crashes against the asynchronous
> nature of the Qt's signal/slot system -- i.e. I got strange behaviour
> past the proxy/adapter layer and working with those pointers inside
> the rest of the application.

I assume you're using signal/slots across threads? Else the connection
would be direct, which means that in fact all slots have been run and
finished when the emit-call returns.

For cross-thread signal/slot connections the default connection type is
QueuedConnection, which posts an event to the event-loop on emit and goes
on with the code. However there's a connection type to block the
emit-return at this point, called BlockingQueuedConnection, so all you'd
have to do is use that connection type when connecting your cross-thread
signals/slots and make sure it doesn't introduce deadlocks, i.e. a signal
is emitted from thread A, connected to a slot in Thread B and the slot
emits a signal as well, which again is connected to a slot in thread A will
not work.

Andreas

-- 
You learn to write as if to someone else because NEXT YEAR YOU WILL BE
"SOMEONE ELSE."