Discussion :

[Invit�]

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

[Invit�]

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�.

[Invit�]

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.