[Qt-interest] What exactly is thread affinity, and what is it for?

[Thiago Macieira]

Em Quinta-feira 20. Maio 2010, às 18.46.34, K. Frank escreveu:
> > The thread affinity is there to tell which thread's event dispatcher
> > shall be used for event-dispatcher activities.
> 
> Is the following correct?
> 
> A thread has an event dispatcher (or has an event dispatcher that is
> properly running) if, and only if the QThread's exec() member function
> has been called (and hasn't blocked or been killed).
> 
> That is, are "event dispatcher," "event loop," and "exec()" basically all
> synonymous?

No.

They are related, but not exactly synonymous.

The event dispatcher is something that exists per thread. It's a class derived 
from QAbstractEventDispatcher and is responsible for polling socket notifiers, 
handling timers and dispatching the events from the event queue.

Event loop is a loop that runs the event dispatcher until the loop is broken. 
The QEventLoop class as well as QCoreApplication::exec / quit and 
QThread::exec / quit are the interfaces to the event dispatcher.

The between event loop and event dispatcher is that you can nest one loop 
inside the other and the outer can only exit once the inner has exited. The 
event dispatcher is something that exists, per thread created with QThread.

> > The event dispatcher does basically three things:
> > 1) it has an event queue
> > 2) it has a list of timers
> > 3) it has a list of socket notifiers
> > 
> > So when a QObject needs to handle any of those three things, it needs to
> > know which thread's event dispatcher it should talk to. The interface to
> > the event queue is QCoreApplication::postEvent; the interface to the
> > timers is QObject::startTimer (and the convenience classes QBasicTimer
> > and QTimer); the interface to socket notifiers is the QSocketNotifier
> > class.
> 
> Let me pose a question about the event queue:  Let's say I have
> 
>    QThread *t1 = new QThread...
> 
> and an object, o1, that was created by t1's thread of execution.
> 
> Any old thread can call QCoreApplication::postEvent (o1, someEvent);. 
> True?

Correct. That function is documented to be thread-safe.

It's roughly equivalent to the pseudo-code:
	o1->thread()->eventQueue.append(someEvent);

> Is it the case that if t1's exec() loop is running, then t1's thread
> of execution will call
> 
>    o1->event (someEvent);

Correct. That's one of the tasks of the event dispatcher: dispatch events by 
calling QObject::event.

> and if t1's exec() loop is not running (wasn't started, or was
> blocked, or killed),
> o1-event() won't be called?

Correct. The event will remain queued and will be delivered once the loop is 
run.

> Is the way postEvent() / event() is handled independent of whether the
> thread of execution that calls postEvent is t1's, itself?

Correct. postEvent() is thread-safe.

-- 
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/20100520/dd4d0666/attachment.bin