Retourner aux forums || Retourner au forum Programmation.perl
Programmation.perl : interdire plusieurs instances du meme programme
Posté par redlums35 () le 11 avril 2005Dans un programme en perl-gtk ? est-il possible d'interdire plusieurs instances du programme / de ne pas avoir la possiblité de le lancer deux fois en meme temps ?
Merci
> Lire le message (4 commentaires, moyenne: 3,3).
locking
Je pense que le mieux est de faire du locking. Par exemple en utilisant flock.
Tout dépend...
... du but de ton interdiction. Si tu cherches à empêcher que l'utilisateur lance "par erreur" le logiciel en double (une sorte d'anti-boulet, en somme), il est assez simple de créer un fichier de "lock" lorsque le programme est lancé, et de refuser de démarrer si le fichier est déjà présent (un tel fichier peut, par exemple, se créer dans ~/.tonprogramme/ ou dans /tmp). Le seul inconvénient de cette approche est qu'en cas de crash, il faut effacer manuellement le fichier-verrou.
Une bidouille permettant d'éviter l'effacement manuel : à la création du fichier verrou, ajouter dedans le PID du processus en cours. En cas de lancement d'une instance du programme, vérifier non seulement l'existence du fichier, mais aussi l'existence d'un processus de même PID que ce qui est indiqué dans le fichier.
Dans tous les cas, tout cela est faisable aussi bien en Perl (gtk ou pas), en Python, en C, en Bash, ...
Par contre, si tu cherches à éviter que l'utilisateur ne puisse parvenir à lancer deux instances du même programme, c'est plus difficile: il pourra toujours éditer ton code et désactiver le test. Pour ça, en dehors d'une solution hard à la palladium (et encore), je ne vois pas trop.
-
[^]Re: Tout dépend...
Posté par Moun's (page perso, ) le 11/04/2005 à 20:10. (lien). Évalué à 2.par rapport au probleme du lock, il peut y avoir des races conditions qui font que le PID dans le fichier puisse etre attribué à un programme voire au programme qui vient de se lancer et qui fait le controle.
il est donc aussi préférable de controler le creation time le comparer à l'uptime de la machine, le last-write par rapport à un processus existant et son uptime.
ne pas oublier de faire un unlink du fichier à la fin du programme ;)
pour empecher ce genre de chose, il suffit d'une gestion de ticket qui donne aussi les tickets d'acces à une base ou un truc du genre ... ce qui fait que si tu n'as pas de ticket pas de données ... donc pas de probleme :)
une couche SSO fait tres bien l'affaire ... il y a CAS dont j'ai entendu parlé qui fonctionne pour la partie SSO en HTTP ( LWP pour perl ), sinon kerberos qui peut etre une usine à gaz.
je me pose la question par rapport à PAM ... pam permettant de controler l'authentification, pourquoi ne pas le mettre de ce coté ? sudo/su/ssh marche avec ... pourquoi pas ton soft ?
par contre, pour PAM, et Kerberos, je ne sais pas quelle est la difficulté pour perl pour ce qui est de CAS, les outils sont là si un outil n'existe pas déjà.-
[^]Re: Tout dépend...
Posté par Matthieu Moy (page perso, ) le 11/04/2005 à 21:00. (lien). Évalué à 3.Dans le cas du fichier "lock", penser aux braves gens qui ont leur /home partagé entre plusieurs machines.
Y'a des bibliothèques toutes faites pour faire du lock de manière fiable (il parait que c'est fiable même sur du NFS, mais j'ai des doutes là).
-
Revenir en haut de page || Retourner aux forums || Retourner au forum Programmation.perl
Cette page a été générée par Templeet en 0.0528s (dont 0.0051 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.