[Qt-interest] Qt signaling smarts...

[Thiago Macieira]

Em Terça-feira 24. Novembro 2009, às 20.01.25, Arnold Krille escreveu:
> On Tuesday 24 November 2009 19:20:41 Gordon Schumacher wrote:
> > Thiago Macieira wrote:
> > > You can always make the middle-man signal be a direct connection:
> > >
> > > connect(&myQThread1,SIGNAL(thread1Signal()),
> > > this,SIGNAL(thread1SignalToThread2Signal(), Qt::DirectConnection)
> >
> > *blink*
> >
> > So, that would be why the sender() docs warn you about threaded
> > DirectConnection... when I read that, I went "why the heck would you do
> > such a thing... bad juju!"  I guess as long as you're not actually
> > accessing any data - as with this example - that would be safe!
> 
> I think here it is safe provided that thread1SignalToThread2Signal is only
> connected to slots/signals in thread2 via QueuedConnections. Once
> thread1SignalToThread2Signal is connected to other slots in main-thread or
>  in a third thread, all hell breaks loose...

In a signal-to-signal connection, it makes no difference. Since the target of 
the connection is QMetaObject::activate anyway (i.e., the signal dispatcher 
code), this will simply cause the second dispatch to be executed from the 
auxiliary myQThread1.

Remember that an auto connection is queued if the *target* object is in a 
different thread. If objects B and C are in the main thread, and you have the 
connection A→B→C and you emit A's signal in the auxiliary thread, it would 
originally cause the first connection to be queued and the second one would be 
DirectConnection. If you force the first one to be direct, B's signal is 
emitted in the auxiliary thread. Buy then the second connection becomes queued 
because C is in a different thread.

This neatly solves the problem of having to go through the main thread to 
dispatch.

Also note that signal emissions are properly locked, so this doesn't risk 
sending events to dead objects. In the case of a race condition, either the 
object's destructor gets there first and disconnects all senders, or the 
dispatcher gets there first and posts the events (which would be deleted by the 
destructor a bit later).

There is still a small race condition if you connect or disconnect in one 
thread while the other emits. No crash will happen, but you may be surprised 
that the connection gets emitted (or not) when you weren't expecting.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091124/c41ead06/attachment.bin