Discussion :

[troumad]

Bonjour

J'aimerai que si j'ouvre à nouveau un programme, ce soit le même programme déjà ouvert qui réponde à la place.
Comme firefox ou openoffice qui n'ouvre pas une nouvelle instance si par un lien quelconque j'ouvre un fichier qui s'adresse à eux( .html pour le premier ou .odt pour le second par exemple).

Système : Linux et Windows

[ram-0000]

Cherche "Single Instance Program" chez note ami Google, il y a plusieurs solutions possibles, après, cela dépend aussi de comment tu veux le faire.

[troumad]

Je pense mettre un lock dans le répertoire où le programme stocke les infos pour les mémoriser d'une session à l'autre.
Je compte aussi mettre des lock lors des ouvertures des fichiers de travail utilisés par mon programme afin de ne les ouvrir qu'une fois.

[Obsidian]

Le plus propre sous UNIX est de déposer un fichier dans /var/lock, qui sert à cela. Le fichier peut être vide ou contenir le PID de l'application. Ce PID peut aussi faire partie du nom du fichier. Idéalement, tu peux aussi créer un socket UNIX nommé de la même façon dans /tmp ou /var/run qui permette de communiquer avec l'application si elle est ouverte.

L'inconvénient de ces méthodes est que, dans les deux cas, le ménage ne se fait pas tout seul si l'application a été tuée brutalement. Il faut donc vérifier si le PID existe toujours, s'il correspond toujours à ladite application ou, le cas échéant, faire le ménage en lançant la nouvelle instance.

Par contre, de grâce, n'utilise pas un port réseau TCP ou UDP pour le faire, comme cela s'est déjà vu sur des applications professionnelles. C'est plus que sale vu de l'extérieur (ton admin système risque de te tuer) et ton application sera impossible à faire tourner sur serveur mutualisé, voire même sur PC avec deux sessions ouvertes.

[troumad]

Idéalement, tu peux aussi créer un socket UNIX nommé de la même façon dans /tmp ou /var/run qui permette de communiquer avec l'application si elle est ouverte.

Cette méthode me conviendrait tout à fait si je savais faire !
Il va falloir que je trouve une doc en français pour apprendre à faire

[souviron34]

sinon, avec getpid, et sous unix en faisant un ps -ef et en lisant la chaine..

[troumad]

sinon, avec getpid, et sous unix en faisant un ps -ef et en lisant la chaine..

Ceci m'informera de la présence active du programme dans la mémoire. Mais comment lui passer un message s'il tourne ?

[Obsidian]

Hello,

sinon, avec getpid, et sous unix en faisant un ps -ef et en lisant la chaine..

Non, ce n'est vraiment pas propre. Un socket UNIX à la bonne place éventuellement flanqué d'un SSID unique si l'on craint vraiment les collisions suffira à remplir toutes les conditions…

Cette méthode me conviendrait tout à fait si je savais faire !
Il va falloir que je trouve une doc en français pour apprendre à faire

Les sockets UNIX se gèrent exactement de la même façon que les sockets réseau Internet, à ceci près que tu utiliseras la famille AF_UNIX plutôt que AF_INET et que tu passeras un nom de fichier avec son chemin plutôt qu'une adresse IP.

Ensuite, tu te « connectes » à ce nom de fichier comme tu te connecterais à un port réseau habituel. Par contre, le nom de fichier aura été ajouté au filesystem et ne disparaîtra pas automatiquement si le processus meurt. Il faudra donc penser à faire le ménage en sortant et/ou éliminer ces sockets morts au lancement d'une instance.

[troumad]

Les sockets UNIX se gèrent exactement de la même façon que les sockets réseau Internet, à ceci près que tu utiliseras la famille AF_UNIX plutôt que AF_INET et que tu passeras un nom de fichier avec son chemin plutôt qu'une adresse IP.

Il faudra donc trouver une doc sur la gestion des sockets réseau Internet

Mon but en faisant ce programme est d'apprendre des choses ! Je crois que je suis sur la bonne voie !

[Obsidian]

Il faudra donc trouver une doc sur la gestion des sockets réseau Internet

Un truc comme ça, quoi :

http://c.developpez.com/cours/?page=divers-c#reseau-c

Attention, toutefois, l'API des sockets est très fouillis de prime abord. C'est plus simple si on connaît leur histoire et leur raison d'être.

[gangsoleil]

Attention, toutefois, l'API des sockets est très fouillis de prime abord. C'est plus simple si on connaît leur histoire et leur raison d'être.

C'est encore pire si on doit gerer IPv6

Sinon, l'ouverture d'une socket est la seule solution reellement propre, car c'est la seule solution qui ne laisse pas de trace en cas de crash du programme. Toutes les autres solutions necessitent des verifications sur la presence du programme en plus du lock (en cas de crash, le fichier de lock reste).

[Obsidian]

Sinon, l'ouverture d'une socket est la seule solution reellement propre, car c'est la seule solution qui ne laisse pas de trace en cas de crash du programme. Toutes les autres solutions necessitent des verifications sur la presence du programme en plus du lock (en cas de crash, le fichier de lock reste).

Même chose pour un socket UNIX, comme dit plus haut : le fichier correspondant doit également être nettoyé à la main… MAIS il reste hors de question d'utiliser un socket réseau à la place.

[gangsoleil]

MAIS il reste hors de question d'utiliser un socket réseau à la place.

Sauf si ton application doit pouvoir etre jointe de l'exterieur.

[Obsidian]

Sauf si ton application doit pouvoir etre jointe de l'exterieur.

Dans ce cas, ce n'est plus le même problème (relis bien le fil).

Si ton application doit pouvoir être jointe de l'extérieur, c'est que c'est en soi une application réseau. Dans ce cas, il y faut choisir un port dédié, etc. et faire une vraie gestion des connexions. Et dans ce cas, évidemment, il est inutile de faire un lock en parallèle à cette connexion.

Toutefois, si ton application concerne uniquement les fichiers (philosophie UNIX) et qu'elle est partagée à travers le NFS, ce sont bien des sockets UNIX qu'il faut créer. Sockets qui, eux, seront partagées vers l'extérieur par le NFS et pas par l'application elle-même.

[troumad]

Dans ce cas, ce n'est plus le même problème (relis bien le fil).

Tu as bien raison !
Le seul but est que le programme ne soit ouvert qu'une fois, même si il édite plusieurs fichiers simultanément.

Il me tarde d'avoir le temps de regarder comment faire tout ça !

[troumad]

http://c.developpez.com/cours/?page=divers-c#reseau-c

On y parle même de socket Windows !
Je commence à regarder

[Obsidian]

On y parle même de socket Windows !
Je commence à regarder

Sous Windows, les sockets fonctionnent un peu différemment. Quitte à faire de la programmation Windows en particulier, il y a d'autres moyens de savoir si une application est déjà lancée. De même que si on se cantonne à Linux, on peut faire les choses différemment, également.

Il y a aussi une option à explorer : DBus (ou autres dæmons de communication du même genre). L'ennui est que tu ne peux pas exiger du système cible qu'il propose ce genre de choses. Par contre, si tu travailles dans un environnement réputé proposer ces facilités, c'est peut-être la meilleure approche à adopter. Cela dit, ce n'est probablement pas plus facile que de créer un socket…

[troumad]

Je fais un programme pour Linux ET Windows !

[troumad]

Je viens de regarder un peu la gestion des sockets. Il y a plein de choses dans plein d'aide. Mais aucune n'est faire comme j'aimerai la trouver. Je ne vais pas me taper une autre publication pour avoir le document dont j'ai besoin ?

Le système en dehors de toute fonction C semble ressembler à ça :
- Un programme en boucle (infinie) qui attend qu'on l'appelle : le serveur. La boucle infinie me gène car il va falloir que j'apprenne une autre notion : faire tourner un petit programme à côté du programme principal (peut-être que gtk gère ça ?).
- Un autre programme qui regarde s'il y a un socket pour récupérer son message et si besoin lui répondre : le fils.

Après, il va falloir que je teste pour voir tout ça. Mais, je n'ai trouvé aucun exemple simple avec AF_UNIX (ni plus compliqué d'ailleurs) pour me permettre de comprendre le fonctionnement. Ça m'aurait servi de première pierre de construction à la compréhension du système. J'espère bien avoir le temps de tester cette semaine, mais aujourd'hui, le beau soleil m'a fait quitter mon PC

Mais ceci ne marchera que pour Linux ? POur Windows, il va falloir que je cherche autre chose ? Il n'y a rien de commun pour les deux à ce niveau ?

[souviron34]

MAIS il reste hors de question d'utiliser un socket réseau à la place.

pourquoi ?