QThread est une interface simple permettant la création et manipulation d'un thread. Pour les versions de Qt inférieures à la 4.4, elle ne peut être instanciée, car la méthode run() est virtuelle pure. Pour les versions plus récentes, la méthode run() est uniquement virtuelle et la classe peut donc être instanciée. Il faut donc créer une classe héritant de QThread et qui réimplémente la méthode run(). Pour les versions de Qt inférieures ou égales à la 4.4, par défaut, QThread exécute une boucle d'événements.

• run() : méthode exécutée par le thread ;
• exec() : fonction bloquante qui va exécuter une event loop dans le thread ; cette fonction ne peut être appelée que par le run() ;
• quit() : slot qui stoppe la boucle d'événements du thread ;
• start() : slot qui lance un thread qui exécute la méthode run() ; cette fonction peut prendre en paramètre la priorité donnée au thread ;
• setPriority() : modifie la priorité d'exécution du thread ;
• wait() : fonction bloquante qui attend la fin de l'exécution ; il est possible de spécifier un timeout.

Cette classe émet le signal started() lorsqu'un thread est lancé et finished() lorsque le thread est terminé.

• sans boucle d'événements : seuls des objets n'héritant pas de QObject peuvent être utilisés. C'est à vous de gérer la condition de sortie de la fonction run(). Un signal étant thread safe, il n'y a aucun problème à en utiliser dans ce cas ;
• avec boucle d'événements : si le thread doit utiliser des objets héritant de QObject, la boucle d'événements doit être exécutée. Pour cela, il suffit d'utiliser la fonction exec() dans la méthode run() ;
• fonctionnement par défaut pour Qt après 4.4 : QThread exécute une boucle d'événements. Le but est alors de transférer les QObject que l'on veut vers ce QThread pour qu'il utilise le thread interfacer pour leur exécution. Cela implique que ces QObject ne doivent être manipulés qu'au travers du système de signaux et de slots de Qt. Sinon les fonctions doivent être thread safe. Attention à la destruction de ces QObject.

• QThread n'est pas un thread et n'appartient pas au thread. Ses slots ne s'exécutent pas dans le thread qu'elle interface ;
• Seule la fonction run() devrait être implémentée. Cette fonction run() est similaire au main() du programme principal. Son exécution correspond au moment où le thread existe réellement ;
• les QObject appartiennent au thread qui les crée. Il faut donc créer/supprimer les QObject utilisés par le thread dans la méthode run().
• Un signal étant thread safe, le thread peut utiliser les signaux du QThread implémenté.

Remarque : Qthread fournit aussi un slot nommé terminate() qui termine brutalement le thread. Cette fonction est à éviter le plus possible.

La grande majorité des API graphiques des divers OS ne sont absolument pas thread-safe. Le traitement IHM dans différents threads peut être la source d'accès concurrents qui peuvent mener à des erreurs fatales de l'application.

C'est pour cela que Qt oblige les traitements IHM dans le thread principal (celui exécutant le main() du programme). Attention, cette vérification est effectuée uniquement par des assertions, en compilation débug.

Si vous devez manipuler l'affichage par un thread, utilisez le système de connexion signal/slot.

Chaque QObject possède une affinité avec un QThread. Et ainsi chaque QObject va utiliser la boucle événementielle exécutée par le thread interfacé par ce QThread.

Par défaut, cette affinité dépend du thread qui crée le QObject. Le QObject prendra le QThread qui interface ce thread. Attention, lorsque l'on crée un QObject, le parent doit être associé au QThread interfaçant le thread.

#include <QtGui>

class monThread : public QThread
{
public :
    monThread()
    {
        QObject obj2;
        qDebug()<< "obj 2  :" << obj2.thread();
    }
protected :
    void run()
    {
        QObject obj3;
        qDebug() << "obj 3  :" << obj3.thread();

        QObject obj4(this);
    }

};

int main(int argc, char *argv[])
{
   QApplication app(argc, argv);
   qDebug() <<"thread principal  :" << app.thread();
   QObject obj1;
   qDebug() <<"obj 1  :" << obj1.thread();
   monThread t;
   t.start();
   t.wait();
   return 0;
}

obj1 et obj2 sont créés par le thread principal et sont associés au même QThread que QApplication. obj3 est créé dans le thread interfacé par QThread et est associé au QThread. obj4 génère un avertissement et son parent est 0.

Il est possible de transférer l'appartenance d'un QObject entre QThread grâce à la méthode moveToThread(). Attention à ces quelques règles :

• seul le thread associé au QThread du QObject doit utiliser cette fonction ;
• le QObject ne doit pas avoir de parent ;
• tous les enfants du QObject sont aussi transférés. Il est donc important que les QObject membres d'une classe dérivée de QObject aient pour parent this (sauf les QWidget) ;
• une fois transféré, le QObject ne doit plus être utilisé par l'ancien thread.

Qt fournit plusieurs possibilités pour manipuler des threads.

• QtConcurrent : un ensemble d'algorithmes simplifiant énormément l'utilisation des threads. Il partage un pool de threads qui s'adaptera à la machine d'exécution.
• QThread : c'est une classe qui interface un thread. Elle va créer, stopper, faire exécuter sa méthode run() et autres opérations sur un thread.
• QThreadPool : pour optimiser la création de threads, il est possible de manipuler un pool de thread avec QThreadPool. Ce pool de threads exécutera des classes héritant de QRunnable et réimplementant la méthode run().

Par défaut, la connexion entre thread est asynchrone, car le slot sera exécuté dans le thread qui possède l'objet receveur. Pour cette raison, les paramètres du signal doivent pouvoir être copiés. Ceci implique quelques règles simples :

• ne jamais utiliser un pointeur ou une "référence non const" dans les signatures des signaux/slots. Rien ne permet de certifier que la mémoire sera encore valide lors de l'exécution du slot ;
• s'il y a une référence const, l'objet sera copié ;
• il est préférable d'utiliser des classes Qt car elles implémentent une optimisation de la copie (cf. COW).

Il est possible d'utiliser ses propres classes. Pour cela, il faut :

• que cette classe ait un constructeur, un constructeur de copie et un destructeur public ;
• l'enregistrer dans les métatypes par la méthode qRegisterMetaType().

class A
{
public :
    A() {};
    A( const A&a) {...}
    ~A() {...}

    ...
}

void desConnect()
{
    qRegisterMetaType <A>("A");
    // Connexion entre deux objets de deux threads
    connect( unObjet, SIGNAL( unSignal(const A &), unObjetDansUneAutreThread, SLOT(monSlot(const A &)));
    connect( unObjet, SIGNAL( unSignal2(A ), unObjetDansUneAutreThread, SLOT(monSlot2(A )));
}

Contrairement aux slots, les signaux sont thread safe et peuvent donc être appelés par n'importe quel thread.

Pour protéger des données partagées entre threads, Qt fournit la classe QMutex. Cette classe fournit une base :

• lock : bloque le mutex ;
• tryLock : essaie de bloquer le mutex (possibilité de mettre un timeout) ;
• unlock : libère le mutex.

Afin de simplifier sa manipulation, Qt fournit la classe QMutexLocker basée sur le pattern RAII qui permet de manipuler correctement le mutex et éviter certains problèmes (un thread qui essaye de bloquer deux fois un mutex, un mutex non débloqué suite à une exception...). QMutexLocker va bloquer le mutex lors de sa création et le libérer lors de sa destruction. Il permet aussi de libérer (unlock()) et de bloquer à nouveau (relock()) le mutex.

QMutex lock;
QMutex lock2;

void f()
{
     // locker bloque le mutex lock
     QMutexLocker locker(lock);
     // on bloque le mutex lock2
     lock2.lock();

     // fonction qui génère une exception
     uneFonction();

     // fonction non appelée suite à l'exception
     lock2.unlock();

     // locker est détruit et va libérer lock
     // malheureusement lock2 est toujours bloqué
}

Lorsqu'une ressource est partagée entre plusieurs threads, ces threads ont le droit d'accéder parallèlement à la ressource uniquement s'ils ne font que des accès en lecture. Ainsi, pour optimiser les accès, Qt fournit QReadWriteLock, qui est un autre mutex, beaucoup plus adapté. Contrairement à QMutex, QReadWriteLock va différencier les lock() en lecture et écriture :

• si un thread essaye de bloquer le mutex en lecture : aucune attente, le thread peut accéder à la ressource ;
• si un thread essaye de bloquer le mutex en écriture : le thread attend la libération du mutex.

• dans les deux cas, le thread attend la libération du mutex.

Comme QMutex, cette classe fournit une base :

• lockForRead() : bloque le mutex en lecture ;
• tryLockForRead() : essaie de bloquer le mutex en lecture (possibilité de mettre un timeout) ;
• lockForWrite() : bloque le mutex en écriture ;
• tryLockForWrite() : essaie de bloquer le mutex en écriture (possibilité de mettre un timeout) ;
• unlock() : libère le mutex.

De la même manière que QMutexLocker, Qt fournit deux classes qui simplifient la manipulation de ce mutex :

• QReadLoker : manipulation du mutex en lecture ;
• QWriteLoker : manipulation du mutex en écriture.

Pour diverses raisons, il peut être intéressant de mettre en pause l'exécution d'un thread pour une durée déterminée. Pour cela la classe QThread fournit plusieurs méthodes statiques :

• sleep : pause le thread pendant n secondes ;
• msleep : pause le thread pendant n millisecondes ;
• usleep : pause le thread pendant n microsecondes.

Il n'y a pas vraiment de meilleure solution. Une possibilité consiste à utiliser QThread comme une sorte de passerelle de signaux et de slots. Pour cela, on tire profit de la possibilité de connecter un signal à un autre.

La technique est très simple. L'instance de QThread :

• ne possède aucun slot, car elle ne doit pas accéder aux objects manipulés par le thread ;
• définira, au besoin, des signaux dans sa définition de base, appelés des signaux sortants ;
• définira, au besoin, à la place des slots, des signaux qui serviront de passerelle vers les slots des objets utilisés par le thread, appelés des signaux entrants ; dans ce cas il faut utiliser la boucle d'événements.

#include <QtCore>
// Simple class qui émet toutes les secondes un entier incrémenté
// Comme un signal est thread safe, le thread appellera le signal de QThread
class threadEmetteur : public QThread
{
Q_OBJECT
protected:
    void run()
    {
        int i=0;
        forever
        {
             sleep(1);
             qDebug()<<"Emission de " << i << " depuis le thread " << (int) currentThreadId();
             emit unEntier(i++);
        }
  }
signals:
  // Émet un entier
  void unEntier(int);
};

// Le second thread doit recevoir des signaux :
// on crée donc une classe qui sera utilisée en interne au second thread
// et connectée aux signaux entrants
class interthreadReceveur : public QObject
{
  Q_OBJECT

public slots:
     // Slot qui affichera un entier reçu
      void afficheEntier(int i)
      {
          qDebug() << "Reçu " << i << " depuis le thread " << (int) QThread::currentThreadId();
      }
};

// Le second thread doit recevoir des signaux et les renvoie vers un objet interne
class threadReceveur : public QThread
{
    Q_OBJECT

protected:
    void run()
    {
        // Création de l'objet interne
        interthreadReceveur receveur;
        // Connexion des signaux entrant vers les slots d'exécutions
        connect(this,SIGNAL( afficheEntier(int)),&receveur,SLOT( afficheEntier(int)));
        // Lancement de la boucle d'événements
        exec();
    }

signals:
  // Signal entrant qui sera redirigé vers l'objet interne
  void afficheEntier(int i);

};

#include "main.moc"
int main(int argc,char**argv)
{
    QCoreApplication app(argc,argv);
    threadEmetteur te;
    threadReceveur tr;
    // Connexion d'un signal sortant vers un signal sortant
    QObject::connect(&te,SIGNAL( unEntier(int)),&tr,SIGNAL(afficheEntier(int)));

    tr.start();
    te.start();
    return app.exec();
}

On pourrait être tenté d'utiliser la fonction moveToThread sur le QThread en début du run() pour exécuter ses slots dans le thread. Seulement, cela poserait des problèmes : par exemple, pour redémarrer le thread après une première exécution, si vous utilisez start() comme un slot.

Avant toute chose, il faut bien comprendre que, dans la grande majorité des cas, les OS font déjà très bien leur travail et que vous n'aurez absolument pas besoin de faire tout ceci puisque le problème est différent selon chaque OS. Ces techniques sont donc, à utiliser en connaissance de cause.

Lorsqu'un thread fait énormément de traitements, il a tendance à monopoliser le maximum de temps CPU. Les autres threads se retrouvent ainsi fortement ralentis voire en attente constante de temps CPU. Il existe quelques solutions pour résoudre ce problème.

• La façon la plus simple est de diminuer la priorité d'exécution du thread. Pour ceci, il vous suffit d'utiliser la fonction QThread::setPriority() avec une priorité inférieure ou égale à QThread::LowPriority.
• La seconde méthode est de mettre en pause régulièrement le thread. Lorsque le thread est en pause, l'OS va récupérer le CPU utilisé par le thread et exécuter un autre thread. Une fois le thread réveillé, il est mis en attente. Le problème de cette méthode est qu'il est assez difficile de déterminer le temps de pause à appliquer. Si le temps de pause est trop faible, le thread va garder l'utilisation du CPU et cela ne réglera pas le problème. Si le temps est trop long, le thread peut être ralenti inutilement.
• Depuis la version 4.5, QThread fournit une méthode publique statique assez intéressante : QThread::yieldCurrentThread(). Avec cette méthode, contrairement à la mise en pause, le thread redonne la main du CPU à l'OS et se met en attente. L'OS détermine quel thread sera exécuté. Ainsi du temps CPU est toujours libéré régulièrement et, en principe, partagé. Il est cependant très difficile d'évaluer la fréquence à utiliser pour appeler cette méthode.

Une méthode intéressante est d'utiliser un QThread comme espace d'exécution d'un QObject. Pour cela il faut que :

• le QThread utilisé lance une eventloop (appel exec()). Depuis Qt 4.4, QThread lance une eventloop par défaut ;
• vos traitements soient implémentés dans un QObject ;
• utiliser moveToThread pour spécifier le thread d'exécution au QObject.

De plus il faut que ce QObject ait certaines propriétés :

• les fonctions appelées entre les thread sont des slots qui ne retournent rien. Ils sont appelés via un connect avec un signal (par défaut, un slot appelé par un connect s'exécute dans le thread du QObject) ;
• le résultat d'une fonction est retourné par un signal ;
• toutes les instances de QObject internes doivent avoir la classe comme parent. Ceci permet que tous les QObject changent de thread lors du moveToThread.

Cette façon de faire a aussi d'autres avantages :

• travailler en mono thread et pouvoir tester son code au maximum avant de passer au multi-threading ;
• équilibrage des charges sur les thread plus facile ;
• évite l'utilisation de mutex & co dans une majorité de cas ;
• développement multi-thread assez propre et simplifié.

Il peut être embêtant de devoir créer des signaux uniquement pour appeler un slot de la classe et un appel direct à la fonction est plus intéressant. Dans ce cas, il faut protéger l'exécution de cette fonction. Avec la classe précédente, comme la fonction est un slot et que le résultat est retourné par un signal, il est très simple de protéger l'appel directement. Pour cela il vous faut créer un QObject qui ne définit que des signaux et dont la classe est déclarée comme amie (friend). Les signaux ont la même signature que les slots de la classe. Il suffit alors de :

• connecter les signaux de cette classe avec les slots correspondants ;
• vérifier à chaque début de slot du QObject, si le thread d'exécution est celui dont le QObject dépend. Si différent, appeler le signal correspondant défini par cette classe. Ainsi, l'appel de la fonction est déplacé dans le bon thread.

Voici un exemple illustrant les explications. Le checkbox moveToThread permet de passer d'un fonctionnement mono-thread à multi-thread. Un clic sur l'image lance une génération.

#include <QtGui>
#include <complex>
const int R_2 = 100000;
const int MAX_TEST = 255;
const int IMG_W = 800;
const int IMG_H = 800;
 
class Generator;
//class interne à generator. Utilisé pour déplacer l'appel d'un slot dans le bon thread.
class GMoveCallToThread : public QObject{
    Q_OBJECT
public :
        GMoveCallToThread(QObject * parent) :QObject(parent) {}
    //réplique les slots de Generator sous forme de signal
signals :
    void generateImage(const std::complex<double> & cc);
    void useThread(QThread *t);
    //generator doit pouvoir utiliser directement les signaux
    friend class Generator;
};
 
 
 
//class qui génère une image.
class Generator : public QObject
{
    Q_OBJECT
 
    //Instance utilisée pour déplacer l'appel d'un slot dans le bon thread.
    GMoveCallToThread  * m_moveCallToThread;
    //indique si un traitement est en cours ou non
    bool m_running;
 
    public :
    Generator(QObject * parent = 0):QObject(parent),m_moveCallToThread(new GMoveCallToThread(this)),m_running(false) {
        //on enregistre la classe std::complex<double>
        //pour l'utilisation des signal/slot en multi-thrread
        qRegisterMetaType<std::complex<double> >("std::complex<double>");
 
        //on connecte les slots avec leurs signaux correspondants
        connect(m_moveCallToThread,SIGNAL(generateImage(const std::complex<double> &)),this,SLOT(generateImage(const std::complex<double> &)));
        connect(m_moveCallToThread,SIGNAL(useThread(QThread *)),this,SLOT(useThread(QThread *)));
    };
 
    //spécifie si un traitement est en cours.
    bool running() {return m_running;}
 
public slots :
    //génère une image de julian avec cc comme nombre constant.
    void generateImage(const std::complex<double> & cc)
    {
        //Si l'appel est dans le mauvais thread,
        //on déplace l'appel vers le bon thread.
        if(QThread::currentThread() != thread())
        {
            m_moveCallToThread->generateImage(cc);
            return;
        }
        m_running = true;
 
        //Calcul de l'image de julian
        QImage img(IMG_W,IMG_H,QImage::Format_ARGB32);
        img.fill(0);
 
        int max = 0;
        QTime t;t.start();
        for(int i = 0; i < IMG_H / 2; ++i)
        {
            for(int j = 0; j < IMG_W; ++j)
            {
                std::complex<double> c = cc ;
                std::complex<double> z (
                                -2. + 4. * j / (IMG_W - 1),
                                 2. - 4. * i / (IMG_H - 1) );
                int nbTest = 0;
                while(std::abs(z) < R_2 && nbTest++ < MAX_TEST )
                {
                    z = z*z + c;
                }
                if(nbTest< MAX_TEST )
                {
                    if (nbTest > max) max = nbTest;
                    img.setPixel(j, i, nbTest);
                    img.setPixel((IMG_W - 1 - j) , (IMG_H - 1 - i) , nbTest);
                }
            }
            //si 40 ms est passé on envoie une image temporaire
            if(t.elapsed()>40)
            {
                emit tmpresult(img,max);
                t.restart();
            }
        }
        //envoie l'image finale
        emit result(img,max);
        m_running = false;
    }
 
    //change l'appartenance du générator à un thread.
    void useThread(QThread *t)
    {
        //Si l'appel est dans le mauvais thread,
        //on déplace l'appel vers le bon thread.
        if(QThread::currentThread() != thread())
        {
            m_moveCallToThread->useThread(t);
            return;
        }
        moveToThread(t);
    }
signals:
    //envoi de l'image finale.
    void result(const QImage &,int);
    //envoi de l'image intermédiaire.
    void tmpresult(const QImage &,int);
};
 
//widget d'affichage.
class maWidget : public QWidget
{
    Q_OBJECT
    //affiche la valeur complexe en fonction de la position de la souris.
    QLabel * m_c;
    //affiche l'image
    QLabel * m_imgDisplay;
 
    //complexe d'initialisation utilisé pour la génération
    std::complex<double> m_z0;
    //Generateur.
    Generator m_gen;
    //thread secondaire.
    QThread m_thread;
 
public :
    maWidget()
    {
        QVBoxLayout * layout = new QVBoxLayout(this);
        {
            //checkbox permettant de spécifier le thread d'exécution du générateur
            QCheckBox * cb = new QCheckBox("MoveToThread");
            connect (cb,SIGNAL(toggled(bool)),this,SLOT(moveThread(bool)));
            layout->addWidget(cb);
 
            m_c = new QLabel("<b>Cliquer sur l'image</b>");
            layout->addWidget(m_c);
 
            m_imgDisplay = new QLabel();
            m_imgDisplay->setMouseTracking(true);
            m_imgDisplay->setPixmap(QPixmap(IMG_W,IMG_H));
            m_imgDisplay->installEventFilter (this);
            layout->addWidget(m_imgDisplay);
            connect(&m_gen,SIGNAL(result(const QImage &,int)), this, SLOT(displayResult(const QImage &,int)));
            connect(&m_gen,SIGNAL(tmpresult(const QImage &,int)), this, SLOT(displayIntermediaire(const QImage &,int)));
        }
        //on lance le thread secondaire.
        m_thread.start();
    }
    //filtre les événements souris du label qui affiche l'image
    bool eventFilter(QObject *obj, QEvent *event)
    {
        if(event->type() == QEvent::MouseMove)
        {
            //si la souris bouge, on affiche la valeur complexe correspondant à la position de la souris.
            QMouseEvent * me = (QMouseEvent *)event;
            std::complex<double> c(-2. + 4.* me->x()/(IMG_W - 1),2. - 4.* me->y()/(IMG_H - 1));
            m_c->setText(QString("<b>Cliquer sur l'image</b> : { %1 , %2 }").arg(c.real()).arg(c.imag()));
        }
        else if(event->type() == QEvent::MouseButtonRelease && !m_gen.running())
        {
            //Si le bouton est relâché et que le générateur est inactif, on lance une nouvelle génération.
            QMouseEvent * me = (QMouseEvent *)event;
            m_z0 = std::complex<double> (-2. + 4.* me->x() / (IMG_W - 1),
                                          2. - 4.* me->y() / (IMG_H - 1));
            m_gen.generateImage(m_z0);
        }
        return QObject::eventFilter(obj, event);
    }
 
    ~maWidget()
    {
        //on stop le thread et on attend sa fin.
        m_thread.quit ();
        m_thread.wait();
    }
 
//convertit une image reçue en QPixmap à afficher.
QPixmap imgtoPixmap(QImage img,int max)
{
    //Création d'une LUT pour convertir les valeurs uint des pixels de img en couleur.
    QColor c(Qt::blue);
    QVector<quint32> LUT(max+1);
    LUT[0] = qRgba(0,0,0,255);
    for(int i =1; i < LUT.size();++i) {
        double p =  pow(double(i) / max, .9);
        if(p>1.) p =1.;
        c.setHslF(c.hueF(), c.saturationF(), pow(p,.5));
        LUT[i] = c.rgba();
    }
 
    //Application de la LUT sur les pixels
    for(int i = 0; i < img.height(); ++i)
    {
        for(int j = 0; j < img.width(); ++j)
        {
            img.setPixel(j,i, LUT[img.pixel(j,i)]);
        }
    }
    //Affiche la valeur complex d'initialisation utilisée.
    {
        QPainter p(&img);
        p.setPen(Qt::red);
        p.drawText(5,15,QString("{ %1 , %2 }").arg(m_z0.real()).arg(m_z0.imag()));
    }
    return QPixmap::fromImage(img);
}
 
public slots :
    //affiche l'image résultat reçu.
    void displayResult(const QImage & img,int max)
    {
        m_imgDisplay->setPixmap(imgtoPixmap(img, max));
    }
 
    //affiche l'image intermédiaire reçue.
    void displayIntermediaire(const QImage & img,int max)
    {
        m_imgDisplay->setPixmap(imgtoPixmap(img, max));
    }
 
    //change le thread du générateur.
    void moveThread(bool b)
    {
        if(b)
        {
            m_gen.useThread(&m_thread);
        }
        else
        {
             m_gen.useThread(thread());
        }
    }
};
 
#include "main.moc"
int main(int argc, char *argv[])
{
    //initialisation de la graine aléatoire.
    qsrand(QTime::currentTime().msecsTo(QTime()));
    QApplication a(argc, argv);
    maWidget w;
    w.show();
 
    return a.exec();
}

On pourrait être tenté de créer un QObject à partir de QThread et d'utiliser la fonction moveToThread sur lui-même en début du run pour exécuter ses slots dans la thread. Seulement, cela poserait des problèmes : par exemple, pour redémarrer la thread après une première exécution, si vous utilisez le start comme un slot…

Il y a deux méthodes basiques pour appeler une fonction à partir d'un thread sur un QObject appartenant à un autre thread :

• la plus simple est de poster un événement sur l'objet à partir de l'autre thread. La boucle événementielle du thread de destination va alors délivrer l'événement sur l'objet de destination ;
• la deuxième approche est d'utiliser la queue de connexions de Qt. Cela est aussi implémenté dans la première méthode et permet d'atteindre n'importe quel objet qui a une boucle événementielle tournant sur le thread auquel appartient l'objet. Vous pouvez même spécifier la queue de connexions en passant en paramètre Qt::QueueConnection à la déclaration de la connexion ou utiliser Qt::AutoConnection, celui par défaut et qui décidera durant l'exécution comment le slot devra être appelé.

Si vous voulez définir l'affinité du processeur pour chaque QThread, vous devrez utiliser des appels aux fonctions natives (ce qui rendra votre programme moins portable !), car Qt ne propose aucune fonction pour le faire. Qt fournit un identifiant natif sur le thread actuellement en exécution avec la fonction statique Qthread::currentThreadId().

Sous Linux, vous devez regarder à la fonction pthread_setaffinity_np() (dans /usr/include/pthread.h). Cette fonction vous permet de définir l'affinité du thread. L'identifiant retourné par QThread::currentThreadId() est le même qu'en utilisant pthread_self(). Afin de changer l'affinité du thread en cours, vous pouvez utiliser un code équivalent à ceci :

CPU_ZERO(&cpuset);
CPU_SET(cpuNumber, &cpuset);
 
pthread_setaffinity((pthread_t) QThread::currentThreadId(), &cpuset);

Vous pouvez utiliser pthread_self() pour éviter un cast.