Discussion :

[fabiop]

Bonjour,

Debian/QTCreator last release.

Je rencontre quelques problèmes avec l'usage de QProcess. J'ai créé une fenêtre qui me permet d'indiquer le nom d'un programme à lancer et les arguments à passer.
A partir d'un bouton démarrer, je lance donc le programme grâce à un QProcess.

Dans un premier cas, je lance un programme test1 de ma fenêtre : pas de problème, ça fonctionne très bien.
Deuxième cas, je lance un programme test2 de ma fenêtre : le programme se lance mais bloque !!

J'ai essayé de varier les OpenMode sans succès. Je n'ai pas d'autres besoin dans ce lancement de connaître la fin du processus (pas d'échanges de données).

Et tout cela avec le même code (ci-dessous)

La différence notable entre test1 et test2 est que dans test2 j'accède à un fichier en lecture !!
J'ajoute que, lancés de la console de commande, test1 et test2 se comportent normalement.

Auriez-vous une piste de recherche, je sèche !!!

Merci d'avance, amicalement.

====
Code
====

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
// QProcess * pr est déclaré dans la classe serveur
 
    serveur::serveur(QWidget *parent) : QMainWindow(parent), ui(new Ui::serveur)
        {
        ui->setupUi(this);
 
        // initialisation de pr
        pr = new QProcess(this->parent());
        // connexion signal - slot
        QObject::connect(pr, SIGNAL(finished(int, QProcess::ExitStatus)), this, SLOT(fin_calcul()));
        }
 
    void serveur::on_bouton_demarrer_clicked()
        {
        // setting de l'environnement
        QStringList env = QProcess::systemEnvironment();
        pr->setEnvironment(env);
        // récupération à partir de QLineEdit du nom de la commande et des paramètres
        QString commande = ui->gene_prog->text();
        QString params = ui->parametres->text();
        if(!commande.isEmpty())
            {
            // lancement du processus
            commande = "uc/" + commande;
            QStringList arguments = params.split(" ");
            pr->start(commande, arguments, QIODevice::NotOpen);
            }
        }
 
    void serveur::fin_calcul()
        {
        ui->bouton_demarrer->setText(QString::fromUtf8("Fin de la génération"));
        }

[Gulish]

On pourrait avoir plus de détails sur " le programme se lance mais bloque" ? Est ton interface qui se bloque, ou le programme lancé dans la console ?

En tout cas, il existe la méthode "startDetached()" dans QProcess, qui fait la même chose que start(), sauf que le process en question est éxécuté dans un nouveau thread (et pas celui de ta GUI). Ca résoudra peut être le problème.

G.

[fabiop]

Pour résumer :

De ma fenêtre Qt (en utilisant QProcess), je lance /sbin/mkdir avec comme argument toto, pas de problème, cela fonctionne aussi bien que lancé d'un terminal.
Je lance un autre programme test1 avec comme arguments 8 2, cela fonctionne aussi bien que lancé d'un terminal.
Je lance mon autre programme test2 avec comme arguments 8 2, le programme se lance mais se bloque avant d'exécuter une opération de sortie mais il ne se termine pas (je suis obligé de tuer le processus à la main). Sous le terminal, il fonctionne parfaitement. La seule différence avec test1 est que je fais une opération de lecture de fichier dans test2, au début du programme.

startDetached() ne change pas le problème et ne me permet plus de détecter la fin du processus.

En tout cas, merci pour ces pistes. Pour l'instant, je fais des essais sur l'environnement du processus selon qu'il est lancé du terminal ou de ma fenêtre Qt.

Amicalement.

[Aurelien.Regat-Barrel]

En tout cas, il existe la méthode "startDetached()" dans QProcess, qui fait la même chose que start(), sauf que le process en question est éxécuté dans un nouveau thread (et pas celui de ta GUI). Ca résoudra peut être le problème.

Oups, je crois que tu te mélanges les pinceaux ! QProcess lance un nouveau processus, aucun thread n'est jamais créé dans le processus père (à l'exception d'un thread de "monitoring" de tous les process lancés dans l'implémentation Win32). startDetached() se contente de lancer le nouveau processus et ne s'en occupe plus, contrairement à execute() qui attend la fin de son exécution pour renvoyer la valeur de retour. Ce sont toutes les deux des fonctions statiques.
Si on utilise une instance de QProcess, alors c'est start().

Pour résumer :

De ma fenêtre Qt (en utilisant QProcess), je lance /sbin/mkdir avec comme argument toto, pas de problème, cela fonctionne aussi bien que lancé d'un terminal.
Je lance un autre programme test1 avec comme arguments 8 2, cela fonctionne aussi bien que lancé d'un terminal.
Je lance mon autre programme test2 avec comme arguments 8 2, le programme se lance mais se bloque avant d'exécuter une opération de sortie mais il ne se termine pas (je suis obligé de tuer le processus à la main). Sous le terminal, il fonctionne parfaitement. La seule différence avec test1 est que je fais une opération de lecture de fichier dans test2, au début du programme.

startDetached() ne change pas le problème et ne me permet plus de détecter la fin du processus.

En tout cas, merci pour ces pistes. Pour l'instant, je fais des essais sur l'environnement du processus selon qu'il est lancé du terminal ou de ma fenêtre Qt.

Amicalement.

L'erreur numéro un est un mauvais répertoire courant. Avant d'appeler execute(), effectue un appel à QDir::setCurrent() pour régler comme tu le veux le répertoire courant du processus à lancer. Sinon, il ne va pas trouver le fichier que tu lui donnes vu qu'il ira regarder dans un autre répertoire...

[fabiop]

C'est ce qui s'est passé à peu près, je n'avais pas le retour d'erreur puisque pas de flux lisible à partir de mon programme lancé !

Merci beaucoup ... Ca m'a permis de bien bosser ce point ! smile

[Gulish]

Oups, je crois que tu te mélanges les pinceaux ! QProcess lance un nouveau processus, aucun thread n'est jamais créé dans le processus père (à l'exception d'un thread de "monitoring" de tous les process lancés dans l'implémentation Win32). startDetached() se contente de lancer le nouveau processus et ne s'en occupe plus, contrairement à execute() qui attend la fin de son exécution pour renvoyer la valeur de retour. Ce sont toutes les deux des fonctions statiques.
Si on utilise une instance de QProcess, alors c'est start().

Es tu sûr ? Sous windows en tout cas, je suis quasiment sûr que l'application appelé est lancé dans un nouveau processus système. Il a même son propre PID, différent de celui de l'application qui l'a lancé. De plus dans la doc, il est écrit :

Starts the program program with the given arguments in a new process

Pour moi, un process est un ensemble de threads. Je vais me renseigner pour être sûr.

G.

Edit : (Je ne parle que de windows, sous unix je ne sais pas)Pour la différence entre start() et startDetached(), tu avais en partie raison, la différence est que l'un attend le retour de l'éxécution, l'autre non. Par contre, selon moi (à confirmer), les 2 fonctions créent un nouveau processus système et donc un nouvel ensemble de threads. J'ai parcouru le code de qprocess et le start appel cette fonction : (et la msdn dit)

CreateProcess Function
Creates a new process and its primary thread. The new process runs in the security context of the calling process.

A confirmer,

G.

[Aurelien.Regat-Barrel]

Es tu sûr ? Sous windows en tout cas, je suis quasiment sûr que l'application appelé est lancé dans un nouveau processus système.

Ben c'est ce que je pensais avoir dit

Par contre, selon moi (à confirmer), les 2 fonctions créent un nouveau processus système et donc un nouvel ensemble de threads.

Oui bien sûr chaque process dispose de son thread principal, mais quand on dit "créer un thread", on parle de créer un thread supplémentaire au sein du processus appelant. Car si on veut être précis, c'est pas QProcess / CreateProcess qui crée explicitement le thread dans le nouveau process, mais l'OS. Pour créer un thread, on utilise... QThread.

Toutes les fonction (start(), startDetached(), execute()) créent un nouveau processus. La différence concerne simplement comment QProcess interagit avec ce processus.