Discussion :

[Bleys]

Bonjour,

bha voila, ma question est dans le titre
Pour être plus précis :
supposons trois Thread T1 T2 et T3

T2 fait une connexion entre le signal p de T1 avec le signal p de T2
T2 fait une connexion entre le signal p de T2 avec le slot q de T3

A l'émission de p depuis T1, Qt va-t-il attendre que T2 soit disponible pour émettre le signal p de T2 (puisque un slot s'exécute normalement dans le Thread de l'objet ayant le slot ... est-ce pareil pour les signaux ?)


Merci de votre réponse

[atttchoum]

Tout d'abord sache que seul un thread qui est entré dans l'eventloop peut exécuter des slot a la réception de signaux. Pour la suite je te conseil la FAQ
Et de t'amuser a faire des test toi même (en utilisant QThread::currentThreadId)
c'est le meilleur moyen de comprendre

[yan]

Je pense que c'est comme pour un slot, le signal sera rémit lors de l'eventloop. Mais je n'en suis pas sure.
Le mieux est bien sure un petit teste
Si c'est bloquant tu peut préciser Qt:irectConnection lors du connect entre les deux signaux.

[gbdivers]

Bonjour

La réponse me semble pas évidente...

On est d'accord que QObject::connect crée une connexion de type Qt:: DirectConnection lorsque les QObject émettant et recevant le signal sont dans le même thread (et donc l'appel est direct) et une Qt::QueuedConnection lorsqu'ils sont dans des threads différents (et donc le traitement du signal passe par la boucle d'événements).

Si on faisait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

emit_de_T1(signal_de_T1) -> slot_de_T2 : emit(signal_de_T2) -> slot_de_T3

les 2 slots seraient exécutés dans les boucles d'événements de T2 et de T3.

Dans le cas d'un signal vers un autre signal, on a 2 informations (légèrement) différentes dans la doc :
1. on crée une Qt::QueuedConnection lorsque les threads sont différents (http://qt.developpez.com/doc/latest/...ctionType-enum)
2. la connexion signal->signal est directe (http://qt.developpez.com/doc/latest/...sandslots.html)

It is even possible to connect a signal directly to another signal. (This will emit the second signal immediately whenever the first is emitted.)

A priori, je dirais que le signal de T2 est émis tout de suite, sans passer par la boucle d'événements (pour moi, le point 1 s'applique que pour les connections signal->slot)

Pour tester, je ne pense pas que QThread::currentThreadId puisse servir (il faudrait le mettre dans un slot de T2 et donc cela pourrait modifier le comportement de la connexion).
Tu peux peut être tester en lancer une boucle d'évènements infinie dans T2 et vérifier :
1. qu'en utilisant un slot dans T2 qui émet vers T3 ne passe jamais
2. qu'en connectant le signal de T1 avec le signal de T2, le slot T3 est exécute.

Si tu fais des tests, tu pourrais mettre le résultat (et le code) ici, pour notre culture générale ?

Au fait, pourquoi cette question ?

[yan]

si la doc le dit, c'est que ça doit être directe.

Comme un signal est threadsafe, il ne peut pas y avoir de problème. Ça parait cohérent.

[Bleys]

Bonjour,

Tout d'abord merci de votre intérêt et investissement pour ma question.

Comme l'a dit gbdivers,personnellement je ne trouvais pas ça spécialement évident (j'ai bien consulté la FAQ avant de venir ici évidemment) et la solution via un test ne m'est pas directement venu à l'esprit mais grâce à vos remarques, je vais pouvoir tester ça.

Cela dit, de part la réponse assez complète de gbdivers, je pense qu'on peut effectivement s'attendre à ce que le signal de T2 soit émis directement. Laissez-moi quelques minutes, je fais un petit programme de test et je vous envoi le code et son résultat

Au fait, pourquoi cette question ?

Je suis en train de concevoir une application, et je constate qu'il est probable que je me retrouve dans cette situation (loin d'être sûr encore). Alors avant d'aller droit dans le mur, je cherche à savoir comment l'émission de ce signal va se passer. Mon problème est que si l'émission du signal de T2 attend que le celui-ci soit disponible, je ne peux pas conserver la conception actuelle (point de vue performances).
Concrètement, entre autres j'ai :

1. Le main thread
2. un thread de traitement
3. un thread d'analyse

Ce que je veux c'est que, à la fin de l'analyse, le traitement exécute une série d'actions (étant donné des valeurs récupérées depuis l'analyse) et que l'analyse se remette alors à analyser de nouvelles données. Comme le traitement et l'analyse ne se connaissent pas, je dois signaler la fin de mon analyse au traitement en passant par le main thread. Or je ne veux pas que l'émission du signal soit ralentit parce que le main thread est occupé.
Si Qt est capable de gérer ça ... je continue tel quel. Maintenant si c'est pas possible, il va juste falloir que je trouve un moyen pour que analyse connaisse traitement et s'y connecte tout seul et directement ou alors synchroniser mes threads via un semaphore

Ai-je répondu à la question ?

Merci encore et à dans quelques minutes pour le test

[Bleys]

Re bonjour,

Ok j'ai finalement fait les tests nécessaires (enfin je crois ). Finalement, la réponse semble être la suivante :
Par défaut, Qt, même s'il s'agit d'une connexion SIGNAL <-> SIGNAL, va attendre que le thread cible concerné soit disponible avant de transmettre le SIGNAL.
Cela dit en forçant la connexion avec un Qt:irectConnection, le signal est transmis même si le thread cible n'est pas disponible (tel est le but de Qt:irectConnection vous me direz).

Pour vérifier cela j'ai utilisé le mini programme suivant (attention, soyons bien clair, c'est un programme de tests : la libération de la mémoire n'est pas gérée et y'avait certainement moyen de faire plus propre notamment au niveau de l'encapsulation, mais là n'était pas l'objectif du test) :

ObjetTest

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
//////////////////////////////////////// ObjetTest.h
#ifndef OBJETTEST_H
#define OBJETTEST_H
#include <QObject>
 
class ObjetTest: public QObject
{
    Q_OBJECT
 
    public:
        ObjetTest();
 
    public slots:
        void Emettre();
        void Recevoir();
 
    signals:
        void signal();
 
}; // class ObjetRecepteur
 
#endif
 
///////////////////////////////// ObjetTest.cpp
#include "ObjetTest.h"
#include <QDebug>
 
ObjetTest::ObjetTest()
    :QObject()
{}
 
void ObjetTest::Emettre()
{
    qDebug() << "Emission signal";
    emit signal();
}
 
void ObjetTest::Recevoir()
{
    qDebug() << "Signal reçu";
}

ThreadTest

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
///////////////////////// ThreadTest.h
#ifndef THREADTEST_H
#define THREADTEST_H
 
#include <QThread>
#include <QSemaphore>
#include "ObjetTest.h"
 
class ThreadTest: public QThread
{
    Q_OBJECT
 
    public:
        ThreadTest(QSemaphore& _synchro, bool inf = false);
        void Emettre();
 
        ObjetTest* Objet;
 
    signals:
        void lancerSignal();
 
    protected:        
        QSemaphore& synchro;
        bool infini;
        void run();        
}; // class ThreadTest
 
#endif
 
 
///////////////////////// ThreadTest.cpp
#include "ThreadTest.h"
#include <QDebug>
 
 
ThreadTest::ThreadTest(QSemaphore& _synchro, bool inf)
    :QThread(), synchro(_synchro), infini(inf)
{}
 
void ThreadTest::Emettre()
{
    emit lancerSignal();
}
 
void ThreadTest::run()
{
    Objet = new ObjetTest();
    connect(this,SIGNAL(lancerSignal()), Objet, SLOT(Emettre()));
    synchro.release(1);
    if(infini)
        for(;;);
    exec();
}

Main.cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
#include <QCoreApplication>
#include <QSemaphore>
#include <QObject>
 
#include "ThreadTest.h"
#include "ObjetTest.h"
 
int main(int argc, char *argv[])
{
    QCoreApplication app(argc, argv);
    QSemaphore synchro;
 
    ThreadTest T1(synchro);         T1.start();
    ThreadTest T2(synchro,true);    T2.start();
    ThreadTest T3(synchro);         T3.start();    
 
    synchro.acquire(3);
 
    /* Scénario 1 */
    //QObject::connect(T1.Objet,SIGNAL(signal()), T2.Objet, SIGNAL(signal()));
 
    /* Scénario 2 */
    QObject::connect(T1.Objet,SIGNAL(signal()), T2.Objet, SIGNAL(signal()), Qt::DirectConnection);
 
 
    QObject::connect(T1.Objet,SIGNAL(signal()), T2.Objet, SLOT(Emettre()));
    QObject::connect(T2.Objet,SIGNAL(signal()), T3.Objet, SLOT(Recevoir()));
 
 
    T1.Emettre();
 
    return app.exec();
}

Les résultats d'exécution sont les suivants :
Scénario 1:

Emission signal

Scénario 2:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Emission signal 
Signal reçu

Ce qui confirme bien que l'on est pas entré dans le Thread de T2 mais que le signal a bien été transmis ... mais bon ... il a fallu qu'on force la main à Qt.
Ce qui donc sous-entend que l'assertion

It is even possible to connect a signal directly to another signal. (This will emit the second signal immediately whenever the first is emitted.)

n'est pas valide ... (ou me trompe-je ?) ... faudrait-il le leur signaler (sans mauvais jeu de mots bien évidemment ) ?


Voilà pour la réponse à la question finalement.

Merci pour votre contribution