Discussion :

[drKzs]

Bonjour,

Je développe un editeur qui ouvre des fichiers en onglets. Mon but est de faire que lorsque l'application est déjà lancée, qu'on l'appelle pour ouvrir un fichier, ce fichier soit ouvert dans l'application (l'instance) déjà en cours.

J'utilise les sockets pour la communication entre les processus, le méchanisme fonctionne à un détail prêt: comment savoir que l'application est déjà lancée ?

Hypothèses de départ:
- essayer de trouver une solution portable (linux/win/mac), au pire des cas utiliser les ifdef par OS
- C++, gtk, stl et glib

Voici à quoi j'ai pensé (ou lu, je n'invente rien)

- le port (prédéfini) est-il déjà occupé lors de la création de la socket ?
Ca oblige à connecter la socket sur un numéro de port fixe, si un autre développeur a fait son appli sur le même que moi, et que son application est lancée, je suis bloqué... Question de probabilités, mais c'est pas très joli non ?

- fichier de lock temporaire ?
Mon fichier sera-t-il bien supprimé en cas de crash(hm) ou autres cas d'arrêts ?

- Regarder la liste des processus ?
Pas très portable ni élégant, mais ça devrait marcher à tous les coups...

Quel est votre avis là-dessus ?

Merci

[ram-0000]

Avec un mutex ?

Dans la FAQ, tu as un exemple de mutex qui empêche de lancer une 2eme instance de la même application, ton problème n'est pas si loin.

[drKzs]

Effectivement ça ressemble à mon problème.

Je n'ai pas tout compris sur la partie mutex. Il me semble qu'il s'agit de gérer différent processus lancé par un même programme et non plusiers lancements d'un même programme ? (j'ai peut-être mal interprété le code, c'est très possible)

1) Le mutex est un membre de la classe, comment peut-il être partagé entre deux instances de l'application ? Quand je lance mon programme, je passe par un main(). Si je le relance je passe encore par le main, mais je n'ai pas de référence commune à un object mutex
>> A moins d'avoir une zone partagé, je regarde actuellement les fichier mappés au cas où ça pourrait m'aider

2) Le mutex est unlocké dans le destructeur, ce qui signifie - un peu comme la solution du fichier temporaire - qu'en cas d'arrêt intempestif ou beau crash le problème sera le même ?

[ram-0000]

C'est un mutex nommé. C'est à dire qu'il est hebergé par le noyau.

La 1ere instance lancée créé le mutex et tente de le prendre et réussi (normal, c'est la première).

Le 2eme instance lancée créé le mutex, tente de le prendre et échoue puisque qu'un d'autre le possède.

Le lien entre les 2 appli, c'est le nom du mutex.

La fonction de base de création des mutex avec WIN32, cest CreateMutex()

Normallement, le mutex est détruit par le noyau si plus aucune application n'a d'attachement dessus (c'est utile en cas de crash de l'appli)

[drKzs]

mutex nommé, je connais pas... Ca a l'air super sympa, je vais faire quelques recherches En espérant que ça existe aussi sous linux, ça semble parfait.
Je reviens pour les infos, merci

[ram-0000]

Sous Linux, les mutex ne sont pas nommé avec une chaine de caractères mais ils sont identifiés avec un nombre, c'est donc presque pareil.

Il suffit que les 2 applis connaissent l'identifiant de ton mutex et le tout est joué.

regarde du côté de semget(), semop() et semctl().

[drKzs]

Oui, j'ai été lire quelques docs, ça a l'air vraiment bien, une solution pratique et élégante J'avais déjà vu ce principe en fait, mais ça fait tellement looongtemps que je ne m'en serai jamais rappelé !

J' ai pas encore été voir la possibilité, mais j'ai eu une autre idée hier, sur le principe des sockets. Si je peux savoir le nom de l'application qui occupe un port donné (je dois différencier le cas où je suis déjà lancé et que j'ai déjà pris ce port pour ma socket, et le cas où quelqu'un d'autre à déjà pris ce port), ça peut être une autre solution. Je vais aussi chercher de ce coté là

[ram-0000]

...Si je peux savoir le nom de l'application qui occupe un port donné (je dois différencier le cas où je suis déjà lancé et que j'ai déjà pris ce port pour ma socket, et le cas où quelqu'un d'autre à déjà pris ce port), ça peut être une autre solution. Je vais aussi chercher de ce coté là

Tous les OS ne donnent pas forcémment cette information.

AMHA, la solution à base de "sémaphore" est la bonne (tout d'abord car elle est transposable à des applications qui n'utilisent pas les socket).

[drKzs]

Effectivement c'est une solution très élégante, j'ai regardé ce matin et c'est assez simple. Malheureusement je suis tombé sur ceci:

Persistence
POSIX named semaphores have kernel persistence: if not removed by sem_unlink(), a semaphore will exist until the system is shut down.

http://linux.die.net/man/7/sem_overview

ll semble donc que dans le cas d'un plantage de l'application le sémaphore soit toujours accessible, et on retombe sur le problème du fichier temporaire :/

[ram-0000]

ll semble donc que dans le cas d'un plantage de l'application le sémaphore soit toujours accessible, et on retombe sur le problème du fichier temporaire :/

Il ne reste plus qu'à faire une application sans bug

[drKzs]

Si seulement !

Je vais chercher du coté des mapped file, au cas où la persistence serait différente, et vers la solution d'identification du voleur de port

[jouana]

Salut,
Sa fait longtemps que j'en et pas fait mais si mes souvenirs sont bon sur le plantage de ton appli le token et libre donc tu peut le reprendre ensuite tu le récupère avec une autre appli et donc il redevient occupé.

Et si ton shm est bien fait il est inscrit dans un fichier en partage c'est le principe du semaphore en même temps

Ce qui persiste c'est le semaphore pas l'occupation mais a vérifié

[drKzs]

Le shm a rapport avec la mémoire partagée ou les sémaphores, je n'ai pas compris ?

Cela dit ton message m'a donné de l'espoir, et j'ai joyeusement testé le crash Malheureusement un semaphore ouvert avec sem_open, et sans sem_unlink ou sem_destroy (pour cause de vilain plantage bouuh) reste locké (errno : déjà existant ou ressource lockée selon le test) reste ouvert snifff :'(

[drKzs]

au temps pour moi concernant shm, tu parles des sémaphores system V (je n'avais pas lu le lien), moi je souhaite rester avec des appel POSIX

[jouana]

Bah sinon c'est pas super mais bon tu enregistre le pid de ton appli qui tourne dans un txt ou autre.
Et après tu vérifie dans l'autre processus si l'id existe si c'est le cas bah tu bloque sinon tu le lance.

[drKzs]

et oui et oui, c'est pas très joli mais c'est simple et efficace, et je n'y avais pas pensé Je crois que je vais me rabattre sur cette solution merci !

Dommage, les sémaphores c'était si joli

[drKzs]

Je reviens juste pour clore, juste quelques ifdef entre linux et mingw, mais ça marche

Merci à tous