Discussion :

[tyrtamos]

Bonjour,

Je cherchais une méthode pour empêcher un programme PyQt4 d'être lancé une seconde fois alors qu'il y avait déjà une instance en activité.

J'ai cherché un code PyQt4 sur le web et je n'en ai pas trouvé. J'ai aussi trouvé des 'usines à gaz' en C++, difficiles à traduire en Python.

Finalement, le plus simple a été de traduire en PyQt4 le code en C de la FAQ Qt: http://qt.developpez.com/faq/?page=q...ples-instances.

Cela a donné le code suivant:

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
 
#! /usr/bin/python
# -*- coding: utf-8 -*-
# Python v2.7
 
import sys
from PyQt4 import QtCore, QtGui
 
#############################################################################
class Fenetre(QtGui.QMainWindow):
 
    #========================================================================
    def __init__(self, parent=None):
        super(Fenetre,self).__init__(parent)
 
 
#############################################################################
if __name__ == "__main__":
 
    # lancement du graphique
    app = QtGui.QApplication(sys.argv)
 
    # on prépare la création d'une zone partagée avec une clé quelconque
    # mais cette clé ne doit pas être utilisée par un autre programme!
    sharedMemory = QtCore.QSharedMemory(QtCore.QString(u"D6BB05B2919732D8F29045842531CAD23162E1B9"))
 
    # on essaye de créer cette zone partagée de taille 50 (quelconque):
    # si ce n'est pas possible, c'est qu'elle existe déjà, et donc
    # qu'elle a été créée par une instance précédente du même programme!
    if not sharedMemory.create(50):
        QtGui.QMessageBox.warning(None,
                         u"Vérification",
                         u"""
 
Attention:
 
ce programme est déjà en cours d'exécution
 
utilisez la version déjà lancée!
 
                         """)
        sys.exit()
 
    # lancement de la fenêtre
    fen = Fenetre()
    fen.show()
    sys.exit(app.exec_())

Le principe est très simple:

1- on créé une clé (une chaine) unique pour le programme concerné

2- on cherche à créer une zone de mémoire partagée avec cette clé

3- si ça ne marche pas, c'est que la zone existe déjà avec la même clé, et donc qu'elle a déjà été créée par une instance précédente du programme.

Pour créer une clé, il suffit que la chaine soit unique. Vous pouvez prendre un GUID comme proposé par la FAQ Qt, mais n'importe quelle chaine peut faire l'affaire. J'ai même essayé avec succès: "nimportequoipourvuquecamousse" . Plus sérieusement, si vous manquez d'inspiration, vous pouvez fabriquer une chaine de 40 caractères au hasard avec:

Code :

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

1
2
3
4
5
 
from random import randint
guidrand = lambda n=40, alphanum=u"0123456789ABCDEF":      ''.join([alphanum[randint(0,len(alphanum)-1)] for i in xrange(n)])
print guidrand()
D6BB05B2919732D8F29045842531CAD23162E1B9

Et ça a l'air de marcher: le 1er lancement du programme se fait, mais le second lancement est empêché (avec message). Ceci à condition de lancer le programme normalement (en console ou un lanceur graphique), et pas à partir d'un outil de développement.

Ça fonctionne de la même façon sous Windows et sous Linux (sous Mac OS_X, je ne sais pas).

Avec cx_freeze sous Windows, ça marche aussi, même si dans certains cas, il faut attendre une minute pour que Windows fasse disparaitre la précédente zone mémoire partagée.

Sous Windows, j'ai même essayé de "tuer" sauvagement la 1ère instance avec le gestionnaire des tâches, pour vérifier que la zone partagée était supprimée aussi: et oui!


Mais alors, quel est mon problème? Il est ici: la méthode me parait tellement simple que j'ai un doute. Aussi, j'aimerais que plusieurs parmi vous essayent pour vérifier que ça marche dans tous les cas!. Il suffit de récupérer le code en copier-coller, et d'avoir déjà Python 2.x et PyQt4.

Si ça marche, en plus de l'utiliser sur mes programmes, je le proposerai à la FAQ PyQt4.

Merci d'avance.

Tyrtamos

[EDIT]: petite modif du code: en cas de détection d'échec, après la fenêtre du message d'erreur, il faut remplacer le simple sys.exit() par:

Code :

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

1
2
3
 
app.quit()
sys.exit(0)

Dans ce cas, ça fonctionne très bien et sans attente avec cx_freeze!

[pacificator]

Bonjour Tyrtamos,

as-tu essayé cette technique: Comment n'instancier qu'une seule fois un programme?

[tyrtamos]

Bonjour pacificator,

Merci de ta remarque. Oui, c'est la 1ère chose que j'ai essayée.

Mais avec un fichier, j'ai la trouille bleue qu'un arrêt anormal de la 1ère instance empêche toute tentative ultérieure d'exécution du programme (même après un reboot!). Il faudra alors accéder au répertoire concerné pour effacer 'à la main' le fichier en question.

Avec un drapeau sur un serveur, le reboot devrait marcher, mais c'est une solution un peu trop 'rustique' à mon goût.

En fait, il faut que dans tous les cas, la fermeture, même anormale, de la 1ère instance fasse disparaitre le drapeau choisi. Et pour ça, il vaudrait mieux que ce soit l'OS qui s'en charge automatiquement. D'où ma proposition.

Tyrtamos

[wiztricks]

Salut Tyrtamos,

Le solution proposée par Pacificator crée un serveur qui écoute sur le port 50000. Comme on ne peut pas créer deux serveurs qui écoutent sur le même port, çà fonctionne modulo un délai d'attente au démarrage suivant.

Par contre, cette technique devrait aussi fonctionner avec un fichier ouvert en écriture - qui par défaut n'est pas "partageable" sauf dans le cas "append".

Les défauts d'une méthode via mémoire partagée sont:
- pourquoi passer par Qt?
- la mécanique sous jacente dépend de l'OS donc la portabilité de ce que tu fais avec devra être testée dans tous les environnements - même en passant par Qt.

- W

[tyrtamos]

Bonjour wiztricks,

Merci de tes remarques.

Pourquoi une solution Qt? Parce que je fais des programmes Qt et que je ne trouve pas de solutions générales.

Je viens d'essayer la solution serveur, et effectivement, elle fonctionne. Mais elle n'a pas que des avantages:
- il faut demander l'accord du parefeu
- il faut supposer qu'il n'y a pas un serveur de port 50000 pour une autre raison
- pour appliquer la méthode à plusieurs programmes, il va falloir leur attribuer un port différent (50001, 50002, etc...) et gérer la liste pour éviter les collisions.

Quand à la solution "on ouvre un fichier en écriture sans le fermer", elle est astucieuse, mais elle ne marche pas. Je viens d'ouvrir 2 instances du même programme qui ont ouvert en écriture le même programme sans broncher. ??? C'est dommage parce que cette solution est très simple.

En plus, dans les OS modernes, on ne peut plus écrire dans la zone d'installation des programmes. Il faut donc chercher une zone publique ou le home de l'utilisateur pour écrire dedans.

Tyrtamos

[wiztricks]

cela aurait été trop simple!
Jettes un œil à https://bitbucket.org/pchambon/python-rock-solid-tools et plus particulièrement au module rsfile
- W
PS: d'après la doc d'os.open le flags os.O_EXLOCK est disponible sur Windows et Unix. Une utilisation pourrait être (ici Python2.7 sous OSX).

Code :

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

1
2
3
4
5
6
>>> flags = os.O_EXLOCK | os.O_RDWR | os.O_NONBLOCK
>>> f = os.open('test.txt', flags)
>>> f2 = os.open('test.txt', flags)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 35] Resource temporarily unavailable: 'test.txt'

[wiztricks]

Autres...

En plus, dans les OS modernes, on ne peut plus écrire dans la zone d'installation des programmes. Il faut donc chercher une zone publique ou le home de l'utilisateur pour écrire dedans.

Comme on souhaite utiliser créer un verrou EX sur la ressource "system wide" matérialisée par le fichier, il n'est pas indispensable d'ouvrir en écriture:
>>> flags = os.O_EXLOCK | os.O_RDONLY | os.O_NONBLOCK
Le fichier peut être un .dat quelconque dans les répertoires du code livré.
- W

[tyrtamos]

Malheurement, mon Python 2.7 sur Windows n'accepte pas ni os.O_EXLOCK, ni os.O_NONBLOCK:

Code :

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

AttributeError: 'module' object has no attribute 'O_EXLOCK'

Et c'est bien dommage: peut-on obtenir un lock d'une autre façon?

Tyrtamos

Edit: c'est dans la notice: ça ne marche que sur Unix. Aucun lock sur Windows.

[wiztricks]

Argh, j'étais parti sur la doc 2.6 et le seul OS ou çà marche (OSX est BSD like).
Désolé, reste à utiliser python-rock-solid
Mais côté portabilité, c'est guère mieux que "shared memory".
- W

[tyrtamos]

Merci wiztricks,

Pour l'instant, c'est donc encore le sharedmemory mon meilleur choix. Il fonctionne sous Windows 7 et sous Ubuntu 2010.10, y compris avec cx_freeze, ce qui me suffit pour l'instant pour mes programmes PyQt4.

J'explorerai la solution python-rock-solid pour les programmes non-PyQt4.

Et donc: je suis toujours intéressé par des avis/essais sur la solution de mon 1er message!

Merci d'avance.

Tyrtamos

[rambc]

Bonsoir.

je suis toujours intéressé par des avis/essais sur la solution de mon 1er message !

Quelques petites modifications sur les chaines et ton code marche sous Python3 avec la nouvelle API de PyQt (plus de QString) :

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
 
#! /usr/bin/env python3
 
# Source
#    http://www.developpez.net/forums/d1029199/autres-langages/python-zope/gui/pyside-pyqt/dde-davis-empecher-2e-execution-programme
 
import sys
from PyQt4 import QtCore, QtGui
 
errorMessage = """
 
Attention:
 
ce programme est déjà en cours d'exécution
 
utilisez la version déjà lancée!
 
"""
 
class Fenetre(QtGui.QMainWindow):
    def __init__(self, parent=None):
        super(Fenetre,self).__init__(parent)
 
if __name__ == "__main__":
    app = QtGui.QApplication(sys.argv)
 
    sharedMemory = QtCore.QSharedMemory("D6BB05B2919732D8F29045842531CAD23162E1B9")
    if not sharedMemory.create(50):
        QtGui.QMessageBox.warning(None,
                         "Vérification",
                         errorMessage)
        sys.exit()
 
    fen = Fenetre()
    fen.show()
    sys.exit(app.exec_())

[tyrtamos]

Bonsoir et merci rambc,

Sur quelle plateforme/OS?

Tyrtamos

edit: je ne comprends pas ta question sur le focus.

[rambc]

Je suis sur Mac OS 10.6.6.

PS : peut-on faire en sorte de mettre le focus justement sur la fenêtre "déjà ouverte" ?

[tyrtamos]

Très bien! Donc, ça marche aussi sur Mac OSX!

Tyrtamos

edit: Pour le focus, je ne sais pas. Il faut que je refasse des essais demain matin.

[Jiyuu]

J'ai déjà eu à traiter ce problème et moi je me suis contenté de créer un fichier quelconque au lancement du programme et de le détruire à sa fermeture.

Seul inconvénient : à l'époque je ne m'étais pas trop attardé sur l'arrêt du programme de manière un peu brutale, et je pense que là, ça peut peut être poser souci.

EDIT:
Oups je viens de m'apercevoir que ceci est repris dans le lien donné par pacificator.

[tyrtamos]

Bonjour Jiyuu,

Merci de ta réponse.

...créer un fichier quelconque au lancement du programme et de le détruire à sa fermeture...

Eh oui, comme tu le dis, un arrêt anormal de la 1ère instance du programme laisserait en place le fichier en question ce qui empêcherait tout autre exécution du programme. C'est tout de même un gros défaut, surtout comme, dans mon cas, pour un programme qui doit être utilisé par un non-informaticien.

On peut au moins placer la destruction du fichier non pas dans la méthode déclenchée par un bouton "quitter", mais dans une méthode héritée à redéfinir: "closeEvent". Ce qui permet de détruire le fichier dans tous les cas "normaux" de fermeture de la fenêtre (bouton 'quitter', croix de la fenêtre ou menu système). Il reste les arrêts causés par des erreurs, ou les blocages nécessitant de "tuer" le programme par l'OS qui nécessiteraient impérativement de détruire le fichier drapeau à la main.

As-tu essayé mon code chez toi?

Tyrtamos

[Jiyuu]

Re,

On peut au moins placer la destruction du fichier non pas dans la méthode déclenchée par un bouton "quitter", mais dans une méthode héritée à redéfinir: "closeEvent"

C'est effectivement comme cela que je ferai.
Gros avantage de PyQt/PySide... en wxPython je n'avais pas réussi à faire ceci (simplement en tout cas).

Je viens de tester.
Il est opérationnel sous :

• Win XP avec Python 2.7
• Debian 6 avec Python 2.6

J'ai essayé avec PySide, il ne fonctionne pas car le module SharedMemory n'est pas présent... il existe peut être autre chose, mais j'ai pas eu le temps de regarder.

Petite aparté...

Quelques petites modifications sur les chaines et ton code marche sous Python3 avec la nouvelle API de PyQt (plus de QString) :

j'ai retiré le QString de la ligne sharedMemory et cela fonctionne très bien avec Python 2.7... c'est grave docteur?

[tyrtamos]

Il est opérationnel sous :

• Win XP avec Python 2.7
• Debian 6 avec Python 2.6

Excellent, merci!

j'ai retiré le QString de la ligne sharedMemory et cela fonctionne très bien avec Python 2.7... c'est grave docteur?

J'ai bonne mine: je n'ai ajouté QString à la dernière minute que pour mieux respecter la notice Qt, mais je ne le mets jamais d'habitude...

Tyrtamos

[rambc]

Bonjour.

j'ai retiré le QString de la ligne sharedMemory et cela fonctionne très bien avec Python 2.7... c'est grave docteur?

Non. Les dernières versions de PyQt font en sorte d'être le plus pythonique possible côté variable, d'où la disparition des QStrings par exemple.

[rambc]

Bonjour.

Une petite idée en passant. Ne serait-il pas possible d'utiliser un thread qui modifierait un fichier toutes les 3 secondes par exemple, le contenu serait la date et l'horaire système au moment de la création ?

Si l'application a été fermée suite à un problème, et qu'elle est ensuite relancée, l'existence du fichier entraînera une lecture du contenu pour décider ou non de lancer l'application.

Est-ce une idée stupide ?