[Qt-interest] Sending a qt signal from pthreads

[Thiago Macieira]

On Monday, 7 de February de 2011 18:37:44 K. Frank wrote:
> If I spawn a pthread, and that pthread creates some sort of
> QObject, what is the tread affinity of that QObject?

Since Qt 4.2, to a QAdoptedThread (internal class) which is created for that 
thread. It's the same QThread sub-class that you get if you call 
QThread::self() in that thread too.

But I would recommend you don't do this.

> Second:
> 
> If a signal and slot are connected with an "auto" connection,
> my understanding is that whether the slot is called synchronously
> ("direct" connection) or asynchronously ("queued" connection)
> is determined by the thread of execution that emits the signal,
> and the thread affinity of the object whose slot receives the signal:
> if the signal thread is the same as the slot thread, the call is
> synchronous, and if they are different, the call is queued.

Yes. Let me emphasise: thread of execution that emits the signal, like you 
said. It has nothing to do with the sender object's thread of affinity.

> What then happens, for example, if pthread A emits a signal
> from object A, and that signal is connected to a slot in object
> B, where object B was created by pthread B?  Since both the
> signal thread and the slot thread are "foreign" threads, how
> does the Qt framework decide whether the call should be
> synchronous or asynchronous?

No difference. If receiver->thread() == QThread::self(), then deliver directly, 
else queue.

If any QObject has a null pointer for thread affinity, then there is no event 
queue to add the event to. The event will just disappear in limbo.

If a QObject has a valid QThread pointer for thread affinity, then that thread's 
event queue is used. This applies even to adopted threads -- they have an 
event queue too. However, remember that events are delivered by the event loop 
and, if none is running, it will never get delivered. Unlike the case above, 
it doesn't disappear: it's still queued. It's just that the queue is never 
drained.

> It's not clear to me how an asynchronous call (queued connection)
> could be implemented, since pthread B doesn't have an associated
> QThread object to which events can be posted, and presumably
> isn't running an event loop that could process such events.

Well, it will happen exactly like how you don't see it happening. There is a 
QThread associated to any thread as long as one of these happened:

1) you started it with QThread
2) you called QThread::self() in that thread
3) you created a QObject in that thread

This includes an event queue too and an event dispatcher. If you want this 
queued drained, you should exec() it.

If you're not going to exec() in that thread, you shouldn't create QObjects in 
it.

-- 
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/20110208/3047ae7c/attachment.bin