Discussion :

[flat]

salut a tous
mon probleme est simple : j'ai un programme P1 qui doit lancer un autre programme P2.
contraintes :
- P1 doit continuer son execution apres le lancement de P2
- doit etre utilisable sous linux et windows (donc on oublie les api)

alors j'ai cogitté et j'ai pensé a ca :
je fais un fork() dans P1 pour créer le nouveau processus
je fais mon test pour savoir si c'est P1 ou P1'
si c'est P1', je fais un exec de P2
probleme : P1' doit connaitre le chemin vers P2. apres le fork le contenu des variables n'est pas copie
je ne dois pas utiliser de fichier pour faire communiquer les 2 processus

si quelqu'un a une solution pour le sujet ou pour mon debut de solution, je suis preneur
merci

[Pouic]

Hmm.... Quelques incohérences et mauvais termes...

- doit etre utilisable sous linux et windows (donc on oublie les api)

et

je fais un fork() dans P1 pour créer le nouveau processus

le jour où tu arrives à faire un fork sur un Windows natif, tu me previens, ça m'interesse

Qu'entends-tu par :

P1' doit connaitre le chemin vers P2.

??

Sinon, utilise les threads POSIX.. (quoique je ne sais pas si ouindoze est conforme POSIX.4... à confirmer...)

[flat]

le jour où tu arrives à faire un fork sur un Windows natif, tu me previens, ça m'interesse

et bien je penser que sous windows fork pouvait fonctionné car fork est déclaré dans unistd.h et je pensais que unistd etait aussi sous windows mais je viens de verifier et j'ai l'impression que non

Qu'entends-tu par :

P1' doit connaitre le chemin vers P2.

??

j'entend chemin vers P2 :
- /usr/bin/programme
ou
- c:\Program Files\Programme\programme.exe

Sinon, utilise les threads POSIX.. (quoique je ne sais pas si ouindoze est conforme POSIX.4... à confirmer...)

il me faut bien un nouveau processus, P1 peut se terminer alors que P2 doit continuer. si j'ai bien compris ce qu'etait un thread, ce n'est pas possible

[Médinoc]

Si, c'est tout à fait possible normalement, le processus est supposé se terminer quand son DERNIER thread se termine.

MAIS:
1° ce n'est peut-être pas le cas des threads POSIX...

2° En Windows natif, il faut terminer le thread de main() par ExitThread() au lieu de return. (la petite subtilité sur laquelle on se prend facilement la tête)

3° Un thread ne peut pas se faire remplacer par un exécutable avec exec() (mais il peut appeler system(), normalement)

[flat]

Merci Médinoc pour ces précisions
J'ai trouvé un compromis pour la portabilité. Pour les fonctions windows que je ne peux pas remplacer, je vais utiliser des ifdef pour que la compilation s'effectue pour l'environnement concerné.
Je vais essayer avec la lib pthread, merci pour vos reponses

[Emmanuel Delahaye]

- doit etre utilisable sous linux et windows (donc on oublie les api)

alors j'ai cogitté et j'ai pensé a ca :
je fais un fork()

Pas de fork() sous Windows.

Les processus ne se gèrent pas de la même façon sous Windows et sous Linux, mais tu peux essayer de créer une couche d'abstraction commune applicative.

(Ca existe peut être, est ton ami)

Sinon, les pthreads (un seul processus, mais plusieurs threads) existent pour les deux plateformes (c'est du POSIX.1, donc indépendant de la plateforme).

Ca dépend de ton application...

[Emmanuel Delahaye]

Merci Médinoc pour ces précisions
J'ai trouvé un compromis pour la portabilité. Pour les fonctions windows que je ne peux pas remplacer, je vais utiliser des ifdef pour que la compilation s'effectue pour l'environnement concerné.
Je vais essayer avec la lib pthread, merci pour vos reponses

Ok, mais par pitié, pas dans le code applicatif. Fait une couche d'abstraction documentée... (fait le bien, ça reservira...)