J'ai un programme qui sous linux.
 
Quand on clique sur l'icône sur le bureau,
parfois le programme se lance 2 fois  
(si on a le doigt trop lourd je pense).
 
Pour éviter des problèmes,
j'aimerais empêcher le programme de se lancer si
il tourne déjà.
 
j'ai d'abord écrit une valeur dans un fichier,
au début du programme je vérifie cette valeur,
et à la fin du programme je remet cette valeur à sa valeur d'origine,
mais si le programme plante, je ne sais pas la remettre à 0.
 
J'ai pensé à ouvrir un port série,
mais apparemment on peut l'ouvrir plusieurs fois
puisque je n'ai pas d'erreur quand je l'ouvre une seconde fois.
 
Ce que j'aimerais c'est un moyen de ce style
qui permettrait de retrouver son état à la sortie du programme,
même en cas de plantage (ce qui est le cas pour l'ouverture d'un port).

 
tu pourrais peut-être regarder dans le liste des processus s'il y en a pas déjà un correspondant à ton appli.

Faut créer un Mutex.
Un article très complet là dessus :
http://www.codeproject.com/cpp/avoidmultinstance.asp
ou si tu es pressé :
http://support.microsoft.com/defau [...] bContent=1
 
Veux-tu limiter ton appli à une instance par utilisateur ou par poste ?

réponse à rufo : pourquoi pas,
mais dans mon cas je fais plusieurs fork,
donc j'ai plusieurs process qui portent le même nom.
 
.....je peux aussi compter ces process,
mais faut que je vérifie qu'il n'y a pas de fork qui se font de temps en temps.....

.....par poste.
 
ça devrait aller avec le mutex.

Ca se complique alors. ca depuis XP, on peut avoir plusieurs sessions ouvertes sur un seul poste. Donc, si j'aibien compris, tu veux que si un utilisateur a déjà lancé le soft, un autre ne le puisse pas.
Les Mutex sont uniques au sein d'une même session. Pour créer un mutex qui soit visible depuis toutes les sessions, faut rajouter "GLOBAL\" devant. Le problème c'est que certaines versions de Windows (Win9x, NT4) ne tolèrent pas d'antislash dans le nom. Donc faut tester l'OS et réagir en conséquence.

......je suis sous linux.
 
De toute façon la question de l'utilisateur ne se pose pas.
C'est une machine qui se trouve en production,
et seul un utilisateur peut se logger dessus.
Donc pas de problème pour cela.

lol

.......zut, au moment où je me met à programmer ça....
un mutex ne peut pas être nommé ???!!!!
 
Comment je peux faire pour initialiser un même mutex
dans 2 process différents ?????

on a dit Linux
 
je te dirai ça ce soir, mais il faut mettre un verrour coopératif sur le fichier qui stock le PID avec fnctl
 
sinon, tu peux effectivement vérifié la liste des processus en cours (ça peut être une méthode supplémentaire)

il n'y a pas simplement des fichiers spéciaux
que l'on ne peut ouvrir qu'une seule fois?
Lorsque le programme se termine,
le fichier serait automatiquement fermé.
 
....je pensais que c'était le cas pour le port série.

ça je sais pas. moi je connais une manière générique, c'est tout. sinon, tu peux utiliser un segment de mémoire partagée

 
C ce que j'allai proposer.

 
oui mais ces processus créés par un fork sont créés par ton processus père. C'est donc lui dont il faut lister ne nb de processus de ce "type"...

Mais comment reconnaitre leprocessus père ?
Les processus fils portent automatiquement le même nom.

getppid()

Merci bien,
mais ce n'est pas le contexte.
 
Comment reconnaitre avec la commande 'ls'
qui est le process père.
En principe celui qui a le pid le plus bas,
mais bon ça devient tout doucement compliqué,
et puis ce n'est pas infaible.
Si les pid font le tour, on recommence au pid 0.....enfin pas le 0 justement, mais bon.
Donc le père aura un pid supérieur aux fils.
 
C'est quoi le principe de la mémoire partagée ?
Je viens d'essayer avec un sémaphore,
mais celui-ci n'est pas supprimé lorsque je fais un Ctrl-C.
C'est pareil avec la mémoire partagée.

OK trouvé,
 
j'ouvre un fichier et je place un lock dessus.
Bizaremment un lock en écriture ne fonctionne pas,
il faut placer un lock en lecture.
 
Ainsi si le programme quitte inopinément,
le descripteur sur le fichier est détruit,
et le lock aussi par la même occasion.

correct. voir ma première réponse.

Tout à fait,
c'est toi qui m'as mis sur la voie.
 
Il m'a fallu tout ce temps
à cause du lock en écriture et non en lecture.