Discussion :

[Boumbata]

Bonjour à tous !!!


Voilà en fait pour résumer grossièrement j'ai à ma disposition deux exécutables A et B. Je réponds tout de suite qu'il n'y a aucun moyen de passer par des dépendances exe/dll, car il y a des problèmes d'incompatibilité avec les dlls utilisées par les deux zigotos

L'exécutable A appelle de temps en temps l'exécutable B pour accomplir une tâche particulière. Auparavant cela suffisait amplement, car l'exécutable B ne renvoyait comme retour qu'un booléen true ou false pour spécifier si le calcul s'était bien déroulé ou non.

Le souci est désormais que l'exécutable A a besoin d'objets qui sont construits à la fin de l'exécution de B.

L'inconvénient c'est que le main de B ne peut renvoyer rien d'autre qu'un int, et bien évidemment il faut envoyer beaucoup plus.

Voici un exemple concret de ce que je voudrais obtenir (je suis sous Windows):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
///
/// main.cpp de A.exe
///
 
#include <iostream> // main
#include <sstream> // ostringstream
 
int main()
{
    const int argument = 3;
    std::ostringstream buffer;
    buffer <<  "B.exe \"" << argument << "\"";
    int resultat = system(buffer.str().c_str()); // appel de l'exécutable B, en lui passant en paramètre "agument"
    // y a t'il un moyen de faire un "MyObject my_object = system(buffer.str().c_str()); ?
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
///
/// main.cpp de B.exe
///
 
#include <iostream> // main
 
#include "MyObject.h"
 
int main(int argc, char* []argv)
{
    if(argc != 2)
    {
         std::cerr << "Erreur: nombre d arguments incorrect" << std::endl;
         return EXIT_FAILURE;
    }
    MyObject my_object = do_something(argv[1]);
 
    // Y a t'il un moyen de faire un "return my_object; " ??
}

[imperio]

Pour passer des donnees entre 2 programmes, plusieurs solutions s'offrent a toi :

- utiliser les pipes : un peu complique a comprendre au debut mais ca vaut le coup
- utiliser les sockets : ma solution favorite generalement
- utiliser les semaphores : pas forcement adapte
- utiliser les fichiers : pas forcement une bonne idee

[Boumbata]

Pour passer des donnees entre 2 programmes, plusieurs solutions s'offrent a toi :

- utiliser les pipes : un peu complique a comprendre au debut mais ca vaut le coup
- utiliser les sockets : ma solution favorite generalement
- utiliser les semaphores : pas forcement adapte
- utiliser les fichiers : pas forcement une bonne idee

Quelle est la différence entre pipes sockets et semaphores ? Fichier j'y ai pensé mais effectivement c'est pas très très safe en fait, d'autant plus que cela force à parser derrière, etc...

[r0d]

Selon ce que tu veux partager, si ce n'est pas trop gros, tu peux aussi utiliser la mémoire partagée. Tu peux par exemple regarder du côté de boost interprocess, qui est très simple à utiliser.
Si ce sont des gros volumes de données, alors l'option base de donnée intermédiaire peut avoir du sens. C'est cependant très rare d'en arriver là.

[Boumbata]

Je n'ai pas trop compris comment est-ce que l'on peut faire passer directement un objet via l'interprocess de boost quelle fonction permet de le faire ?

Dans mon cas c'est bon ce ne sont pas de grosses données qui sont transférées

[r0d]

Je n'ai pas trop compris comment est-ce que l'on peut faire passer directement un objet via l'interprocess de boost quelle fonction permet de le faire ?

Il y a plusieurs façons de faire. La plus simple est de nommer des zones de mémoires partagées. Regarde cette page par exemple. Ce n'est pas ce qu'il y a de plus safe, mais il y a de grandes chances pour que tu n'aies pas besoin de plus, et quoi qu'il en soit, ça te permet de tester l'api.

[jblecanard]

Salut

- utiliser les pipes : un peu complique a comprendre au debut mais ca vaut le coup
- utiliser les sockets : ma solution favorite generalement

Sous Linux, les pipes sont encore plus simples à utiliser que les sockets ! Bon on parle sous Windows, je ne sais pas.

D'un point de vue workflow, l'usage des pipes et des sockets sont très similaires : on streame des données dans un descripteur de fichier. Le gros avantage des sockets est que le jour ou tu passe sur du réseau avec des exécutables sur des machines différentes, il n'y a que de la configuration à faire. Du reste, passer de socket à pipe ou l'inverse se fait assez bien. Exemple avec libevent qui te permet d'implémenter la couche applicative sur des FDs sans te préoccuper de ce qu'il y a en dessous (pipes, fichiers, sockets, peu importe !).

La mémoire partagée, je ne suis pas pour. Déjà parce que c'est pas très évolutif, mais surtout parce qu'avec les architectures de processeurs modernes, ce n'est pas très adapté, ça va faire des invalidations de cache à tout va.

[imperio]

@jblecanard: le probleme avec les sockets c'est qu'il faut que tu "aies la main" sur le code des deux executables parce que sinon il ne risque pas de se passer grand chose si on a un serveur sans client ou l'inverse. Dans le cas present, le probleme ne se pose pas mais sait-on jamais...

L'avantage du pipe c'est qu'au moins tu peux recuperer la sortie du programme sans avoir a toucher au code source, mais je trouve qu'on est un peu plus limite.

La mémoire partagée, je ne suis pas pour. Déjà parce que c'est pas très évolutif, mais surtout parce qu'avec les architectures de processeurs modernes, ce n'est pas très adapté, ça va faire des invalidations de cache à tout va.

Je ne vois pas trop de quoi tu veux parler... Si tu parles des semaphores, on s'en sert en permanence (sans forcement le savoir d'ailleurs), ce serait problematique si ca posait des problemes sur les processeurs modernes... Par-contre si tu parles des ipc, c'est vrai que j'en ai pas rencontre souvent, mais une fois de plus je ne vois pas trop ce qui pourrait poser probleme...

Pour ce qui est des fichiers, il me semble avoir utiliser une sorte de shared file un jour dans un projet pour mon ecole (sous linux par-contre), mais je ne me souviens plus du tout de comment ca s'appelle. Si quelqu'un a une idee de ce dont je suis en train de parler ?

[jblecanard]

Je ne vois pas trop de quoi tu veux parler... Si tu parles des semaphores, on s'en sert en permanence (sans forcement le savoir d'ailleurs), ce serait problematique si ca posait des problemes sur les processeurs modernes... Par-contre si tu parles des ipc, c'est vrai que j'en ai pas rencontre souvent, mais une fois de plus je ne vois pas trop ce qui pourrait poser probleme...

Lorsque tu es dans une architecture multi-coeurs, tes processeurs n'accèdent pas aux données directement en RAM, il y a plusieurs niveaux de cache. SI par malchance tes données partagées sont sur des processeurs qui ne partagent pas leur cache, elles vont passer leur temps à faire du ping pong entre les deux caches... dans certains cas vicieux, ce type d'effet de bord peut salement pourrir tes perfos. Ca ne provoque pas particulièrement de plantage cela dit.

Pour ce qui est des fichiers, il me semble avoir utiliser une sorte de shared file un jour dans un projet pour mon ecole (sous linux par-contre), mais je ne me souviens plus du tout de comment ca s'appelle. Si quelqu'un a une idee de ce dont je suis en train de parler ?

Tu n'aurais pas utilisé /dev/shm par hasard ? C'est un système de fichier monté en RAM.