Comment est-il possible d'interdire à un programme de se lancer 2 fois? Ce qui permettrait d'éviter d'accéder et de modifier les mêmes ressources, avec les comportements erratiques que ça peut impliquer...
d'avance merci!
[edit]Résolu à peu près...

Citation : huit_six

Comment est-il possible d'interdire à un programme de se lancer 2 fois?

Rien de standard. Quel système ? Quel type d'application ? (console, TUI, GUI, daemon ...)

Snif, grosse déception.
Il s'agit d'un petit jeu en SDL, moi je l'utilise sous linux (ubuntu), mais je veux qu'il soit portable au moins sous windows et plus si affinités possible...
Du coup si je comprend bien, je vais être obligé d'installer windows pour compiler/déboguer mon programme? Moi qui pensais avoir enfin réussi à me débrouiller sans...

Dans le principe, tu crées un fichier dont tu testes l'existence à chaque lancement de ton programme. C'est la méthode la plus simple.

Citation : huit_six

Snif, grosse déception.
Il s'agit d'un petit jeu en SDL, moi je l'utilise sous linux (ubuntu), mais je veux qu'il soit portable au moins sous windows et plus si <...>

J'ai dit "rien de standard", j'ai pas dit "rien de portable". Il se peut que SDL fournisse un moyen. Tu sais où trouver la doc...

Citation : rz0

Dans le principe, tu crées un fichier dont tu testes l'existence à chaque lancement de ton programme. C'est la méthode la plus simple.

C'est peu-être la plus simple, mais elle peut rater de manière assez barbare non ? Je m'explique : supposons que pour empêcher le double lancement de ton programme, tu teste si "test.test" existe. Si c'est le cas, tu ferme ton programme, sinon tu le crée, et qu'à la fin de ton programme tu le supprime.
Maintenant imaginons que pour une raison inconnue, ton programme ne parvienne pas jusqu'à la destruction dudit fichier : il plante avant ! Alors à son prochain lancement, il verra le fichier (à tort, puisqu'une seule instance sera lancée) et se fermera.
Et généralement au niveau du SiteDuZero, les tests nécessaires à l'allocation mémoire et autres ne sont pas fais donc si le programme est distribué personne ne peut affirmer qu'il ne va pas aller sur un ordinateur ayant trop peu de mémoire pour allouer une variable, d'où le crash et toutes ses conséquences...

Bon, après, j'admets que c'est la méthode la plus simple (mais qui nécessite tout de même plein de précaution).

Le must serais de trouver la manière de la faire pour chaque OS et de définir une macro qui teste la double instance et qui change selon l'OS qui compile (et donc qui exécute).

Mouais bon, le coup du fichier c'est pas mal, je pense que je vais tenter un truc comme ça, ensuite en mettant un message d'erreur assez explicite au lancement du programme ça doit être possible déviter le genre de problème que tu mentionnes <!--nico-->, un truc du genre "il semble que le programme machin soit déja lancé, si ce n'est pas le cas, supprimez le fichier truc muche et relancez l'application..."
par contre pour la SDL j'ai cherché vite fait et j'ai rien trouvé.
Je pensais qu'il était possible de connaitre la liste des processus actifs et d'y repérer notre programme, m'enfin... tant pis!
Merci du coup de main!

Recupérer la liste des processus actifs, c'est possible, mais je pense pas que tu puisses faire ça de manière portable, alors que la manière du fichier l'est.

Citation : <!--nico-->

Citation : rz0

Dans le principe, tu crées un fichier dont tu testes l'existence à chaque lancement de ton programme. C'est la méthode la plus simple.

C'est peu-être la plus simple, mais elle peut rater de manière assez barbare non ? Je m'explique : supposons que pour empêcher le double lancement de ton programme, tu teste si "test.test" existe. Si c'est le cas, tu ferme ton programme, sinon tu le crée, et qu'à la fin de ton programme tu le supprime.
Maintenant imaginons que pour une raison inconnue, ton programme ne parvienne pas jusqu'à la destruction dudit fichier : il plante avant ! Alors à son prochain lancement, il verra le fichier (à tort, puisqu'une seule instance sera lancée) et se fermera.
Et généralement au niveau du SiteDuZero, les tests nécessaires à l'allocation mémoire et autres ne sont pas fais donc si le programme est distribué personne ne peut affirmer qu'il ne va pas aller sur un ordinateur ayant trop peu de mémoire pour allouer une variable, d'où le crash et toutes ses conséquences...

Bon, après, j'admets que c'est la méthode la plus simple (mais qui nécessite tout de même plein de précaution).

Le must serais de trouver la manière de la faire pour chaque OS et de définir une macro qui teste la double instance et qui change selon l'OS qui compile (et donc qui exécute).

Bah après, il existe des tas de méthodes plus évoluées mais le principe est là : On crée une ressource externe et on teste si elle est utilisée. Un peu plus évolué, il y a la technique du lockfile+pid (unix-like). On crée le lockfile et on met le PID dedans, mais pareil, il y a des risques de problèmes et il faut prévoir un moyen de forcer l'exécution (par exemple un flag -f en ligne de commande). Sinon, en plus compliqué mais normalement pas facilement contournable sans faire exprès, il y a l'utilisation de tout ce qui est de l'ordre des communications inter-procédures (IPC), sémaphores et mutexes marchent bien pour ça. Voir semget() et semop() pour POSIX, et CreateSemaphore(), OpenSemaphore(), ReleaseSemaphore() et WaitForSingleObject() (+ les mêmes avec Mutex à la place de Semaphore) pour Windows.