Comment savoir si mon application est deja lancée

**mercure07** · 15/05/2008, 11h26

Salut tout le monde, je suis en train de compiler mon application développée avec Qt4.3 sous Mac OS X 10.4 Tiger PPC. J'ai un traitement qui fait la mise à jour automatique de l'exécutable et pour cela j'ai besoin de savoir si mon application est déjà lancée ou pas (elle tourne ou pas). Es ce que quelqu'un pourrait m'indiquer une méthode d'avoir cette information sous Mac.
Merci de vos réponse

**IrmatDen** · 15/05/2008, 13h45

Salut,

Si tu disposes d'une license commerciale, alors il y a une solution QtSingleApplication dispo chez TT qui remplit ce rôle de façon multi-plateforme.

Sinon, plusieurs options:

créer un fichier de lock (à supprimer lors de la fermeture de l'appli bien sûr)
occuper une socket durant le cycle de vie de l'appli, et checker sa disponibilité au démarrage de l'instance
prendre des solutions spécifiques à la plateforme (mais plus risqué que la solution basée sur les sockets à ce qu'il paraît dû au haut risque de non libération après un crash => reboot nécessaire):
- win32: mutex
- linux: sémaphore
- osx: sémaphone aussi je pense puisque c'est basé sur linux

**Alp** · 15/05/2008, 13h49

La solution "artisanale" du fichier de lock semble être correcte en effet IrmatDen.
Cela consisterait à créer un fichier au lancement de l'application et à le supprimer à la fermeture.
Ainsi, si le fichier existe déjà, c'est que l'application est déjà lancée et qu'elle n'est pas fermée -> cela interdit le lancement de toute autre instance de ton application.

**IrmatDen** · 15/05/2008, 13h55

Seul problème (mais gros), en cas de crash, le fichier existe, et il faut prévoir un mode "recovery" au lancement de l'application avec tout les risques que ça implique.

**Alp** · 15/05/2008, 13h56

Oui. C'est une technique plutôt artisanale mais qui n'est pas assez fiable selon les cas.

**Fabllot** · 15/05/2008, 14h02

Bonjour !

Envoyé par Alp

La solution "artisanale" du fichier de lock semble être correcte en effet IrmatDen.

Cependant cela pose tout de même le problème du plantage de l'application : on est obliger de supprimer manuellement le fichier lock pour pouvoir relancer le soft.

Envoyé par IrmatDen

# prendre des solutions spécifiques à la plateforme (mais plus risqué que la solution basée sur les sockets à ce qu'il paraît dû au haut risque de non libération après un crash => reboot nécessaire)

Mmm... Je suis septique pour la non libération... J'utilise cette méthode sous Windows, et malgré les plantages réguliers de mon appli, je peux relancer aussitôt une nouvelle instance sans soucis ! Et je viens même de m'apercevoir que le mutex que je crée n'est même pas détruit à la fin de l'exécution et il n'y a aucun soucis par la suite !
Après pour les sémaphores & Unix je ne sais pas...

Pour ma part, j'opterais donc pour la solution avec des sockets... (qui peut cependant être "lourde" pour une appli Qt, si on n'utilise pas le framework QtNetwork ailleurs...)

**Alp** · 15/05/2008, 14h04

En effet, cela oblige à lier l'application au module QtNetwork et c'est une solution lourde à mettre en oeuvre. Cela dépend donc de la nature du programme (personnel, professionnel) ainsi que de son importance. Par contre, c'est clairement la solution la plus fiable.

**yan** · 15/05/2008, 14h50

Je me demande si avec Qt 4.4 il ne serait pas possible d'utiliser qsharedmemory
http://qt.developpez.com/doc/latest/...y.html#details

**IrmatDen** · 15/05/2008, 15h00

Envoyé par Fabllot

Après pour les sémaphores & Unix je ne sais pas...

Ca a été confirmé par un linuxien en fait d'où la précision

**Aurelien.Regat-Barrel** · 15/05/2008, 15h57

Envoyé par IrmatDen

osx: sémaphone aussi je pense puisque c'est basé sur linux

sur bsd

Dans le cas d'une appli liee au hardware, on a besoin de s'assurer d'une mono instance sur la machine, a contrario de la mono instance "classique" par session utilisateur. Ainsi sous Windows par exemple, depuis XP et le "Fast User Switching", on peut avoir plusieurs users logges simultanement, chacun faisant tourner dans sa session ton appli mono instance... Evidement, idem sous unix.

Les approches fichier/socket ne sont pas impactees par cet aspect, contrairement aux objets nommes comme les mutex (cependant, sous Windows au moins, on peut aussi nommer un objet "globalement")

**mercure07** · 16/05/2008, 17h54

Juste pour vous communiquer la solution que j'ai trouvé. Elle plutot simple et trés facile à implémenter. En fait elle consiste en l'utlisation de QProcess et la commande shell ps :
QProcess process;
process.start("bash", QStringList()<< "-c" << "ps xc | grep monApp | grep -v grep");
QByteArray result = start.readAll();
Et ça marche, il suffit de tester sur la valeur de result.
Merci à tout le monde pour leur aide précieuse.

**yan** · 16/05/2008, 17h57

Envoyé par mercure07

Juste pour vous communiquer la solution que j'ai trouvé. Elle plutot simple et trés facile à implémenter. En fait elle consiste en l'utlisation de QProcess et la commande shell ps :
QProcess process;
process.start("bash", QStringList()<< "-c" << "ps xc | grep monApp | grep -v grep");
QByteArray result = start.readAll();
Et ça marche, il suffit de tester sur la valeur de result.
Merci à tout le monde pour leur aide précieuse.

Ca marchera que sous linux mais interessant

**Aurelien.Regat-Barrel** · 17/05/2008, 13h23

Attention avec ce genre de solution basees sur le nom de l'exe : si on renomme ton programme, c'est fini...

**Alp** · 17/05/2008, 13h42

Mais avec QApplication on peut récupérer le nom, non?

**Aurelien.Regat-Barrel** · 17/05/2008, 14h05

Yes, mais ca n'empeche pas que MonApplication1 et MonApplication2 peuvent tourner en "meme temps"

**Aurelien.Regat-Barrel** · 17/05/2008, 14h08

En fait il y a aussi un autre aspect, c'est si une autre appli (pas la tienne) porte le meme nom. C'est peu probable bien sur... mais sur un appel a grep en plus... Murphy et sa loi sont la, n'oubliez pas