Instance unique d'une application portable

**shenron666** · 02/12/2008, 20h46

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

**ram-0000** · 02/12/2008, 20h52

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

**shenron666** · 02/12/2008, 23h22

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

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

**3DArchi** · 03/12/2008, 11h39

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.

**shenron666** · 04/12/2008, 17h06

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

**Davidbrcz** · 04/12/2008, 23h21

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

**3DArchi** · 05/12/2008, 09h05

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.

**Davidbrcz** · 05/12/2008, 17h02

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.

**ram-0000** · 05/12/2008, 17h59

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

**Obsidian** · 06/12/2008, 01h35

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.

**Obsidian** · 06/12/2008, 01h59

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.

**jmv** · 19/12/2008, 23h28

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

**loufoque** · 20/12/2008, 18h00

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...