• # locking

    Posté par  (site web personnel) . Évalué à 2.

    Je pense que le mieux est de faire du locking. Par exemple en utilisant flock.

  • # Tout dépend...

    Posté par  . Évalué à 6.

    ... 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  (site web personnel) . É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  (site web personnel) . É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à).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.