Instance unique d'une application portable

Bonjour,

Je cherche à limiter le lancement d'une application portable à une seule instance.

Sous windows à ma connaissance, la meilleure méthode consiste à créer un mutex nommé mais pour m'appuyer sur une bibliothèque portable de qualité j'ai regardé du côté de boost qui malheureusement ne permet pas la création d'un mutex nommé.

D'où la question suivante : est-ce que cela est possible également sous linux ?

Si vous avez connaissance d'une méthode, si possible autre que le lock d'un fichier, je suis tout ouïe ;)

Il me semble que sous linux, le premier paramètre à semget() est un identifiant de semaphore arbitrairement choisi par l'utilisateur.

D'accord, ce n'est pas un nom mais c'est un nombre.

Peut être que tu peut prendre les 4 premiers caractère du nom de ton sémaphore pour créer cet identifiant. Voire même faire un hash sur ce nom pour calculer cet identifiant.

il va falloir jouer du #ifdef si tu veux un code compilable quelque soit la cible

dans le même ordre d'idée, comment faire communiquer 2 processus sous linux ?

avec semget également pour récupérer le sémaphore créé par l'un des processus ? et ce afin que les 2 processus partagent le même sémaphore ?

si je ne trouve rien qui couvre cela de manière portable il faudra que je suive ta suggestion et m'y coller à grand coups de conditions de compilation :aie:

merci pour ton aide ram-0000, je vais commencer par me reseigner plus en détail sur semget et tourner autour, voir si je trouve d'autres infos

Citation:

---

Envoyé par shenron666

Bonjour,

Je cherche à limiter le lancement d'une application portable à une seule instance.

---

wxWidget offre une classe pour cela wxSingleInstanceChecker. Mais elle est déclinée en 2 versions: sur windows, c'est effectivement un mutex, sur unix, j'ai cru comprendre qu'elle utilise un fichier.

j'hésite à utiliser le système de fichier (lockfile)
c'est peut-etre la solution la plus simple et portable
à voir si elle présente des inconvénients

Bah si l'application plante sans détruire le lock, il est nécéssaire de le faire sauter à la main.

En survolant la version wxWidget, j'ai cru comprendre que le premier process inscrit son PID dans le fichier. Ce qui peut permettre de vérifier s'il existe un process avec le même PID en cours et sinon de considérer comme 'mort accidentellement' et de pouvoir gérer le cas où l'appli plante sans avoir à supprimer le fichier à la main.
J'y vois une autre limitation: lancement de l'appli à partir d'un CD avec aucun droit d'écriture sur le poste. Là, on ne sais plus créer ce fichier.

Citation:

---

Envoyé par 3DArchi

J'y vois une autre limitation: lancement de l'appli à partir d'un CD avec aucun droit d'écriture sur le poste. Là, on ne sais plus créer ce fichier.

---

Là, il suffit de créer le fichier dans une zone accessible par tous.
Sous Un*x, typiquement /tmp, sous windows aucune idée mais ca devrait se trouver.

Citation:

---

Envoyé par Davidbrcz

Là, il suffit de créer le fichier dans une zone accessible par tous.
Sous Un*x, typiquement /tmp, sous windows aucune idée mais ca devrait se trouver.

---

Le répertoire pointé par la variable d'environnement TEMP ou TMP

Hello,

Les fichiers de lock sont une technique répandue sous Unix, BSDs compris, sous Linux. Il y a un répertoire de dépot attitré : /var/lock. Il sert à ça et est défini pas le FHS (pitié : pas dans /tmp). Il ne faut pas hésiter à l'utiliser car les administrateurs système les connaissent et vont les chercher à cet endroit si une application ne démarre pas (c'est mieux avec un message d'erreur, quand même).

Sinon, il existe aussi les futex Linux mais je ne les ai jamais utilisés.

Enfin, il existe une solution alternative au fichier de lock ordinaire : le socket UNIX. Le point de communication est un nom de fichier (et pas un port réseau, ce qui est atroce mais néanmoins répandu), et doit être effacé manuellement par l'application ou l'administrateur, comme un fichier ordinaire, mais au moins on peut communiquer avec l'application qui est derrière et vérifier qu'elle répond.

Citation:

---

Envoyé par shenron666

dans le même ordre d'idée, comment faire communiquer 2 processus sous linux ?

---

Cas d'école. Ce sont des techniques que l'on regroupe sous le terme d'IPC (Inter-Process Communication), bien que les IPC Sys V soient une API particulière proposant sémaphores, file de messages et mémoire partagée. En gros, tu peux utiliser :

- Le pipe. Nommé (sur le système de fichier ou non). Ça a l'air empirique comme ça, mais il ne faut pas hésiter à l'utiliser. Et même à en ouvrir plusieurs si besoin est. Se gère comme un fichier, donc il faut qu'un processus père les ouvre et en fasse hériter ses processus fils.

- Les IPC Sys V. Historiquement, le système de communication proposé par la dynastie des Sys V. Sémaphores, file de messages, et segment de mémoire partagée (extrêmement utile). Chaque ressource est repérée par un identifiant. Pas de problème quand celui-ci est distribué par le système, mais risque de collision si le numéro est codé en dur dans l'application (même problème que pour choisir un port TCP, par exemple). L'ennui, c'est que ces identifiants restent en mémoire et que cela brise un peu la philosophie « tout est fichier » d'UNIX.

- Les sockets. C'est initialement la réponse de BSD à ce même problème. C'était censé être un système de communication universel, ce qui explique un peu le fouillis de l'API consacrée. Du côté processus, un socket est repéré par un descripteur de fichier, de l'autre côté, ce socket peut-être relié à n'importe quel point de communication sur lequel on pourra se connecter. Ça peut être un port réseau, une entrée sur le filesystem, et c'est à peu près tout en l'état actuel des choses.

- Les signaux : kill est un truc qui se rapproche de l'interruption logicielle. Ça préempte ou/et interrompt un processus en cours qui appelle alors un handler dédié. Ça sert en principe à gérer les évenements du système (interruption de l'utilisateur, pipe cassé, division par zéro, segfault, échéance d'un timer système, etc), mais il a aussi les signaux SIGUSR1 et SIGUSR2, soit des signaux « utilisateurs » qui, par défaut, ne font rien. Évidemment, les signaux ne servent pas à faire du message-passing directement (c'est un peu violent). Par contre, c'est un excellent moyen de prévenir le processus qu'il y a quelque chose à aller lire ou chercher. De nombreuses applications (Apache, par exemple), relisent leur fichier de configuration quand elles reçoivent ce signal.

- Le fichier. C'est vrai pour les systèmes. C'est pas forcément souhaitable mais une quantité de données peut très facilement être déposée dans un fichier par un processus puis lue par un autre. En ce sens, ça rentre dans le cadre de la communication inter-processus.

je crois que la librairie QT propose des mutex nommés.

Regarde du côté de Boost.Interprocess. Ça supporte tout et de manière portable.
Shared memory, Memory mapped file, Process-shared mutex types, Process-shared semaphore, Process-shared condition, File lock, Message queue, Named mutex, Named semaphore, Named condition...

Citation:

---

Envoyé par loufoque

Regarde du côté de Boost.Interprocess. Ça supporte tout et de manière portable.
[...]
Named mutex

---

Perfect, well done, merci :D

j'était passé à côté en me limitant à boost::threads :oops:
j'ai remplacé mon mutex nommé "win32" en boost::named_mutex et c'est nickel

merci loufoque ;)