Discussion :

[yan]

[edit] Ceci est une discussion déplacée d'un autre sujet


C'est pas terrible l'exemple de mandelbrotalors...
http://qt.developpez.com/doc/4.3/threads-mandelbrot/
il utilise un signal :

renderedImage(const QImage &, double)

C'est pas thread safe!!!
Surtout qu'avec le COW,

renderedImage(const QImage, double)

Aurai suffit!!! ou y as encore un truc qui m'échappe?

[IrmatDen]

Si, grâce à l'utilisation d'une QWaitCondition sur la variable restart qui n'est positionné à true, que lorsque tu zoom/drag.
Une boucle du code de run n'est exécuté qu'à ces moments, pas en permanence. Hors, lorsque l'image est accédée dans le thread GUI, il est *impossible* de faire un rendu d'image puisque les zoom et drag sont contrôlés par le thread GUI. D'où l'impossibilité de corrompre cette image.

Mais en effet, un const QImage aurait été suffisant (et je n'ai pas de réponses à pourquoi utiliser une ref constante dans la majorité de ces cas :/)

[yan]

J'ai enfin compris une grande partie du schimilibilik.
Merci pour la patience
Nykoo, si tu veut bien, je veut bien faire la partie sur le connect entre thread?

Bon faudra que je regarde cette histoire de QWaitCondition. Je voit pas pourquoi ca rendre safe l'échange de l'image entre les deux thread...

Merci

[IrmatDen]

En fait non, c'set moi qui ai lu le code trop rapidement tout à l'heure, mea culpa (désolé de t'avoir induit en erreur, par contre, j'ai l'explication réélle ce coup-ci )

J'ai un peu fouillé les sources concernant QPixmap, et en fait fromImage (tant qu'elle de format RGB32, ARGB32_Premultiplied ou RGB16) fait simplement un pixmap.data->image = image; (cf src/gui/image/qpixmap_raster.cpp)
Donc en réalité, l'assignation est immédiate (puisque cow) et lors de la modification dans le thread, les données de QPixmap sont "déliées" des données de l'instance QImage dans le thread.
Donc en fait l'image est à cause de ça incorruptible. (Et par parallèle, j'aurais tendance à dire que la ref const QString& suit le même principe si tu ne l'utilises pas telle quelle, mais en l'assignant à une variable locale)

[yan]

En fait non, c'set moi qui ai lu le code trop rapidement tout à l'heure, mea culpa (désolé de t'avoir induit en erreur, par contre, j'ai l'explication réélle ce coup-ci )

Héhé ca me rassure

J'ai un peu fouillé les sources concernant QPixmap, et en fait fromImage (tant qu'elle de format RGB32, ARGB32_Premultiplied ou RGB16) fait simplement un pixmap.data->image = image; (cf src/gui/image/qpixmap_raster.cpp)
Donc en réalité, l'assignation est immédiate (puisque cow) et lors de la modification dans le thread, les données de QPixmap sont "déliées" des données de l'instance QImage dans le thread.
Donc en fait l'image est à cause de ça incorruptible. (Et par parallèle, j'aurais tendance à dire que la ref const QString& suit le même principe si tu ne l'utilises pas telle quelle, mais en l'assignant à une variable locale)

Je ne suis pas d'accord , ce n'est pas incorruptible. Mais c'est peu probable.
1- Une image est généré et un signale est envoyé
2- Un event est émis dans la thread principale
3- Seulement la thread principale fait un truc super long
4- l'autre thread à déjà commencé à faire quelque chose puisque reçu un nouveau zoom et position auparavant => modifie la QImage
5- Et la la thread principale traite l'event => QImage as changé => corrompu

Je suis d'accord que dans ce code c'est peu probable. Mais dans un autre code...

[IrmatDen]

3- Seulement la thread principale fait un truc super long
4- l'autre thread à déjà commencé à faire quelque chose puisque reçu un nouveau zoom et position auparavant => modifie la QImage

Ces 2 points sont incompatibles
Si le thread principal fait un truc long:
> pas possible de faire de zoom
> pas possible de faire un drag
> possible qu'il y ait une ou plusieurs itérations supplémentaire dans le thread
> mais comme il ne peut pas y avoir de rafraichissement entre temps puisque le thread GUI est occupé à autre chose, tout va bien (je parle toujours dans ce cas bien sûr).

Bien sûr, dans un vrai soft il est préférable de partir sur une autre solution (par exemple, un "anneau" d'images, ie, tu as 10 instances de QImage dispo dans le thread, chaque fois qu'une est générée, tu utilises la suivante en émettant la dernière créée; arrivé à la 10ème, tu repars de 0 en partant du principe que la première a largement eu le temps d'être utilisée. Si elle est pas, y'a quelque chose qui va *vraiment* pas du côté de la gui )

[yan]

[QUOTE=IrmatDen;2914051]Ces 2 points sont incompatibles
Si le thread principal fait un truc long:
pas possible de faire de zoom => Ok
pas possible de faire un drag => OK

> possible qu'il y ait une ou plusieurs itérations supplémentaire dans le thread
> mais comme il ne peut pas y avoir de rafraichissement entre temps puisque le thread GUI est occupé à autre chose, tout va bien

Justement, une fois la tache longue fini, si la GUI traite l'event pendant l'itération dans l'autre thread y as corruption

[IrmatDen]

Justement, une fois la tache longue fini, si la GUI traite l'event pendant l'itération dans l'autre thread y as corruption

Bah non, pas ici. Puisque dès que le slot est exécuté, l'image est copiée. Dès la première modif, le lien entre la QPixmap en GUI et la QImage dans le thread est coupé.
Et comme tu le disais, si la GUI est occupé longuement à autre chose (ce qui est bien sûr très mal), les slots sont appelés successivement, mais la référence, elle, reste la référence de la même image puisqu'il n'y en a pas eu de créée entre temps.

Déplie à la main, ça pourrais peut-être t'aider à comprendre l'enchaînement.

Edit: par contre, c'est super HS, tu veux peut-être créer un autre thread pour éviter de polluer celui ci plus qu'il ne l'est déjà?

[yan]

Bah non, pas ici. Puisque dès que le slot est exécuté, l'image est copiée. Dès la première modif, le lien entre la QPixmap en GUI et la QImage dans le thread est coupé.
Et comme tu le disais, si la GUI est occupé longuement à autre chose (ce qui est bien sûr très mal), les slots sont appelés successivement, mais la référence, elle, reste la référence de la même image puisqu'il n'y en a pas eu de créée entre temps.

Déplie à la main, ça pourrais peut-être t'aider à comprendre l'enchaînement.

C'est bien ce que j'ai fait.. J'ai peut etre zappé une étape. Je regarderai mieux ca plus tard
Toute façon la conclusion est :
"c'est mal d'utiliser les références et pointeurs avec un signal"

Edit: par contre, c'est super HS, tu veux peut-être créer un autre thread pour éviter de polluer celui ci plus qu'il ne l'est déjà?

Je déplacerai cette partie dans un autre thread. Mais avant de faire des bétisses je vais demander comment faire

[yan]

bon y as peut être un truc ou je me trompe :
1-la thread calcule une image
2- pendant ce temps, la GUI va demander un zoom
3-la thread calcul toujours mais va relancer une génération aprés car restart passe à true;
4-Problème dans la GUI, elle se fige quelque temps
5-la thread as fini l'image, emet un signal, et relance une génération. Un event est créé dans la GUI
6- La GUI se défige et traite l'event :

• lancement de la conversion de l'image vers une QPixmap
• l'autre thread est en train de modifié la même QImage

Il y as donc bien corruption!!!

[IrmatDen]

Tu as oublié le copy on write

[yan]

Tu as oublié le copy on write

Ha oui tien j'avais pas vu qu'il recréé un image à chaque génération .
Par contre l'image aurait pu être détruite... Car le const QImage & ne va pas utiliser le COW!!!

[IrmatDen]

Ha oui tien j'avais pas vu qu'il recréé un image à chaque génération .
Par contre l'image aurait pu être détruite... Car le const QImage & ne va pas utiliser le COW!!!

Non, en effet. Mais c'est juste au début du slot que cette manip est faite. Au pire du pire, il pourrait y avoir quelques scanlines de la nouvelle, mais dans cet exemple, ça ne peut décemment pas arriver (parce que la GUI ne fait rien).

Si ça arrive dans une GUI plus complexe, et/ou qui aura eu un freeze, l'effet le plus visible, si tant est que l'on connaisse les différentes étapes, sera de voir que tu n'as pas vu un certain nombre d'étapes et que tu aurais eu direct une image quasi finie voire finie. Ce qui reste tout à fait acceptable pour un exemple

[yan]

Non, en effet. Mais c'est juste au début du slot que cette manip est faite. Au pire du pire, il pourrait y avoir quelques scanlines de la nouvelle, mais dans cet exemple, ça ne peut décemment pas arriver (parce que la GUI ne fait rien).

Je parlais d'une QImage. Donc ce que tu dit n'est pas possible car il génère à chaque fois dans une nouvelle QImage temporaire. Mais y aurais pu avoir un crash car utilisation dans la GUI d'une QImage temporaire détruite. Mais vu comment sont agencé les appels a render et les mutex. Ca n'arrivera pas..

Mais bon on va pas se battre
merci de tes explications. J'ai compris pas mal de chose.

[yan]

Bon. J'ai fait un test avec les connects entre thread
Déjà le code de test :
myThread.h

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
55
56
57
58
59
60
#ifndef MY_THREAD_H
#define MY_THREAD_H
 
#include <QtGui>
 
//Structure de test pour le connecte
struct myTest
{
    myTest() ;
    ~myTest();
    myTest(const myTest &) ;
myTest & operator=(const myTest &) ;
};
 
//Boutton qui emet un signal apres un click
class myButton :public QPushButton
{
    Q_OBJECT
 
    public :
    myButton( const QString & text, QWidget * parent = 0 ) : QPushButton(text,parent) {};
    void mouseReleaseEvent ( QMouseEvent * event );
    myTest test;
signals:
    void mySignal( const myTest & );
 public slots:
    void mySlot(  const myTest & );
};
 
 
//thread secondaire qui recoie le signal
class myQObject :public QObject
{
    Q_OBJECT
    public :
    myQObject(QObject * parent = 0 ) : QObject(parent) {};
    myTest test;
    void envoiSignal() {emit mySignal(test);}
signals:
    void mySignal( const myTest & );
    public slots:
    void mySlot(  const myTest & );
};
//thread secondaire qui recoie le signal
class myThread :public QThread
{
    Q_OBJECT
    public :
    myThread(bool sender = false) : QThread(),m_sender(sender) {m_pObj_BeforStart=new myQObject();};
    myTest test;
    bool m_sender;
    void run();
    myQObject * m_pObj_BeforStart;
    myQObject * m_pObj_AfterSTart;
    public slots:
    void mySlot(  const myTest & );
    signals:
    void mySignal( const myTest & );
};
#endif

myThread.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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
#include <myThread.h>
#include <windows.h>
#include <iostream>
 
myTest::myTest() { std::cout<< "create myTest"<<std::endl;}
myTest::~myTest(){std::cout<< "delete myTest"<<std::endl;}
myTest::myTest(const myTest &) { std::cout<< "copy myTest => serialisation"<<std::endl;}
myTest & myTest::operator=(const myTest &) { std::cout<< "egale myTest"<<std::endl;return *this;}
 
 
void myQObject::mySlot( const myTest & )
{
    Sleep(1000);//Pour ne pas ecrie sur la console en meme temps
    std::cout<< "myQObject thread"<<std::endl;
}
 
void myThread::mySlot( const myTest & )
{
    Sleep(1000);//Pour ne pas ecrie sur la console en meme temps
    std::cout<< "myThread slot"<<std::endl;
}
 
void myThread::run()
        {
        m_pObj_AfterSTart =new myQObject();
        if (m_sender)
            {
            //l'event loop de la thread n'est pas lance.
            forever
                {
                std::cout<<std::endl<<std::endl;
                std::cout<< "myThread emit signale"<<std::endl;
                emit mySignal( test);
                m_pObj_BeforStart->envoiSignal();
                m_pObj_AfterSTart->envoiSignal();
                std::cout<< "myThread emit finish"<<std::endl;
                sleep (10 );
                }
            }
        else
            {
            //lance l'event loop de la thread
            exec () ;
            }
        };
 
 
 void myButton::mouseReleaseEvent ( QMouseEvent * event )
 {
    event->accept ();
    std::cout<< "myButton emit signale"<<std::endl;
        emit mySignal(test);
    std::cout<< "myButton emit finish"<<std::endl;
 }
void myButton::mySlot( const myTest & )
{
    Sleep(1000);//Pour ne pas ecrie sur la console en meme temps
    std::cout<< "slot thread"<<std::endl;
}

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
35
36
 
#include <myThread.h>
 
int main(int argc, char* argv[])
{
    bool thread_send_signal = false;
    myThread *pThread = new myThread(thread_send_signal);
    pThread->start();
 
    QApplication app(argc, argv);
 
    myButton *pButton= new myButton("test");
 
    pButton->resize(75, 30);
 
    qRegisterMetaType<myTest>("myTest");
 
    if (pThread->m_sender)
        {
        QObject::connect(pThread, SIGNAL(mySignal( const myTest &  )), pButton, SLOT(mySlot( const myTest & )));
        // QObject::connect(pThread->m_pObj_BeforStart, SIGNAL(mySignal( const myTest &  )),pButton , SLOT(mySlot( const myTest & )));
        // QObject::connect(pThread->m_pObj_AfterSTart, SIGNAL(mySignal( const myTest &  )),pButton , SLOT(mySlot( const myTest & )));
        }
    else
        {
        QObject::connect(pButton, SIGNAL(mySignal( const myTest &  )), pThread, SLOT(mySlot( const myTest & )));
        //QObject::connect(pButton, SIGNAL(mySignal( const myTest &  )), pThread, SLOT(mySlot( const myTest & )),Qt::QueuedConnection);
        //QObject::connect(pButton, SIGNAL(mySignal( const myTest &  )), pThread->m_pObj_BeforStart, SLOT(mySlot( const myTest & )));
        //QObject::connect(pButton, SIGNAL(mySignal( const myTest &  )), pThread->m_pObj_AfterSTart, SLOT(mySlot( const myTest & )));
        }
 
 
    pButton->show();
 
    return app.exec();
}

[yan]

ce que l'on constate (cas ou l'autre thread est créé par la première):
1- un connect d'un objet de la première thread vers le slot de l'autre thread est direct

2- un connect d'un objet de la première thread vers le slot d'un objet de l'autre thread créé avant éxécution de l'autre thread est direct

3- un connect d'un objet de la première thread vers le slot d'un objet de l'autre thread créé après éxécution de l'autre thread est non direct

4- tous signal emit de l'autre thread vers la première thread pendant son exécution est non direct (correpond a l'exemple mandelbrot)

5- un connect de la forme QObject::connect(pThread, SIGNAL(mySignal( const myTest & )), pButton, SLOT(mySlot( const myTest & ))); est sérialisé en recopiant l'objet myTest passé en paramètre!!! quand la connection est non directe (correpond a l'exemple mandelbrot)

6- les référence doivent être const

7- pour executer l'event loop d'une thread il faut appeler exec();

[Matthieu Brucher]

1) pas clair, c'est dans quel cas ?
2) normal puisque le deuxième thread n'est pas encore lancé, il n'y a qu'un seul thread et la connexion est alors directe. C'est logique mais il est vrai que ça peut nécessiter un avertissement lors d'une Q/R ou d'un tutoriel.
3) normal
4) idem que le précédent, c'est normal
5) Rassurant !
6) Là encore, c'est logique, sans le const, l'objet n'est une constante et c'est comme un pointeur, il ne devrait donc pas y avoir de recopie et donc il existe un risque.
7) comme marqué dans l'aide

[yan]

1) pas clair, c'est dans quel cas ?

QObject::connect(pButton, SIGNAL(mySignal( const myTest & )), pThread, SLOT(mySlot( const myTest & )));

2) normal puisque le deuxième thread n'est pas encore lancé, il n'y a qu'un seul thread et la connexion est alors directe. C'est logique mais il est vrai que ça peut nécessiter un avertissement lors d'une Q/R ou d'un tutoriel.

Oui et non. non réciproque à la 4.

4) idem que le précédent, c'est normal

non reciproque à la 2

5) Rassurant !

Je trouve aussi mais ca ne semble pas logique à première vue.

Code :

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

6) Là encore, c'est logique, sans le const, l'objet n'est une constante et c'est comme un pointeur, il ne devrait donc pas y avoir de recopie et donc il existe un risque.

Mais c'est vrai aussi pour les connection direct. C'est important de le savoir

7) comme marqué dans l'aide

Oui c'est juste une remarque. Je vais essayer de mettre tous ca dans une ou plusieur Q/R

[yan]

?
2) normal puisque le deuxième thread n'est pas encore lancé, il n'y a qu'un seul thread et la connexion est alors directe. C'est logique mais il est vrai que ça peut nécessiter un avertissement lors d'une Q/R ou d'un tutoriel.

Je refais ma réponse. Non dans mon exemple le deux thread sont créé avant le connect!!! et la deuxième est lancé depuis un moment. C'est même le tout début du main!!
Le truc est que l'objet est créé pendant la création du thread et non aprés son lancement. Il sera ainsi considéré comme appartenant à la première thread!!!

[Matthieu Brucher]

Oui, c'est normal. Et le premier point est aussi normal car le thread est un objet et il est assigné au thread d'où il a été créé, d'om le problème pour un slot sur ce second thread. ce cas est explicitement marqué dans la documentation, il me semble.
Si tu veux déplacer un objet dans un autre thread, tu dois le faire explicitement (toujours encore indiqué dans la doc).