C++

Question pour un champion [1]

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : Question pour un champion [1]

docmaboul

Soit une jolie instance de classe allouée en shared memory.
Soit un fou ne possédant pas gcc et n'ayant pas d'option pic ou équivalent sur son compilo.
Comment fera notre fou pour appeler les méthodes de son objet directement dans les différents process l'utilisant ?

En clair, comment fera-t-il :

Code :

class blabla
{
public:
// ...
void toto(int);
// ...
};
// pObjetBlabla est en shared
void func(blabla * pObjetBlabla)
{
// ...
pObjetBlabla->Toto(0);
// ...
}

astuce: c'est faisable.

Publicité

Taz

bisounours-codeur

Code :

#include <iostream>
#include <stdexcept>
extern "C"
{
#include <unistd.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/wait.h>
}
class Foo
{
char filler;
public:
void bar()
{
std::cout << "Hello\t"
<< getpid() << '\n';
}
};
class ErrnoError
: public std::runtime_error
{
public:
ErrnoError()
: std::runtime_error(strerror(errno))
{}
};
int main(int argc, char *argv[])
try
{
key_t key = ftok(argv[0], 42);
if(key == -1) { throw ErrnoError(); }
int shm = shmget(key, sizeof(Foo), IPC_CREAT | 0600);
if(shm == -1) { throw ErrnoError(); }
void * const mem = shmat(shm, NULL, 0);
if(not mem) { throw ErrnoError(); }
Foo *f = new(mem) Foo;
switch(fork())
{
case -1:
throw ErrnoError();
case 0:
std::cout << getpid() << " a été créé par " << getppid() << '\n';
f->bar();
shmdt(mem);
break;
default:
wait(NULL);
f->bar();
shmdt(mem);
if(shmctl(shm, IPC_RMID, 0) == -1) { throw ErrnoError(); }
}
}
catch(std::exception &e)
{
std::cerr << "Aïe\t" << e.what() << std::endl;
}

docmaboul

Groumf, j'ai oublié de préciser que la classe se trouve dans une librairie chargée dynamiquement, par le code, au runtime.

Mea culpa.

(mais c'était tellement facile que t'aurais pu te douter qu'il y avait une couille dans le steak là)

Taz

bisounours-codeur

DocMaboul a écrit :

Groumf, j'ai oublié de préciser que la classe se trouve dans une librairie chargée dynamiquement, par le code, au runtime.

et ça change quoi ?

DocMaboul a écrit :

(mais c'était tellement facile que t'aurais pu te douter qu'il y avait une couille dans le steak là)

t'as jamais fait la preuve de tes compétences

Taz

bisounours-codeur

DocMaboul a écrit :

la classe se trouve dans une librairie chargée dynamiquement

DocMaboul a écrit :

Soit une jolie instance de classe allouée en shared memory.

et après si tu commençais à bien nommer les choses, on comprendrais mieux. la provenance de la classe n'a aucune importance. dès que t'en as la définition, tu cases tes instances où tu veux

docmaboul

Taz a écrit :

et après si tu commençais à bien nommer les choses, on comprendrais mieux.

Mea culpa again.

"la provenance de la classe n'a aucune importance. dès que t'en as la définition, tu cases tes instances où tu veux"

pas tout à fait. Si tu ne fais pas un fork mais que tu utilises réellement deux programmes différents, l'histoire n'est pas la même.

En plus, je ne te demande pas du code mais la méthode à utiliser (mais si tu veux mettre le code, libre à toi). Et je précise bien, cette fois, : que la méthode en question marche aussi sous windows.

Message édité par docmaboul le 04-03-2004 à 16:52:16

Taz

bisounours-codeur

mais tu veux faire quoi ? si tu veux partager une instance, il faut de la mémoire partagée ou tout autre mécanisme de communication à la IPC

docmaboul

Taz a écrit :

t'as jamais fait la preuve de tes compétences

Oui : je n'ai rien à prouver. Ni à toi ni à personne d'ailleurs.

Bon, et pour revenir au sujet, t'as trouvé la solution, champion ?

docmaboul

Taz a écrit :

mais tu veux faire quoi ? si tu veux partager une instance, il faut de la mémoire partagée ou tout autre mécanisme de communication à la IPC

Bon, je reformule. Le contexte est :
Soit deux programmes partageant une même zone de mémoire (la méthode de sharing, je m'en fous)
Les deux programmes chargent la même librairie au runtime.
Un des deux (peu importe lequel) crée une instance de classe dans la mémoire partagée.
La classe en question est définie dans la librarie.

Le problème est :
trouver une méthode pour pouvoir utiliser les méthodes de la classe directement dans les deux programmes (la méthode doit aussi marcher sous windows).

Taz

bisounours-codeur

ben mon code réponds à ton problème. le processus initial crée un segment de mémoire partagée, y instancie un objet, et un autre processus (ici créé par fork pour avoir à réécrire les instructions pour attacher le segment de mémoire). et les deux programmes utilisent le même objet. le processus initial a également la charge de détruire le segment partagé

Publicité

docmaboul

Taz a écrit :

malheureusement non car sans pic, les fonctions de l'objet pointeront sur des adresses relatives à l'adressage du programme ayant créé l'objet. Et l'autre plantera.

Taz

bisounours-codeur

ben vois avec ton système.

chaimoiçamarche

docmaboul

Taz a écrit :

ben vois avec ton système.

chaimoiçamarche

A d'autres : c'est du pipeau.

blackgoddess

vive le troll !

en passant par une interface et en faisant un allocateur commun ?

c le 1er truc qui me passe par la tete, je v tester ^^

---------------
-( BlackGoddess )-

Taz

bisounours-codeur

BlackGoddess a écrit :

en passant par une interface et en faisant un allocateur commun ?

c le 1er truc qui me passe par la tete, je v tester ^^

ben c'est en simple ce que fait le placement de new. et ça fonctionne bien

blackgoddess

vive le troll !

bon, j'ai trouvé une solution sous windows, je sais pas si c'est ce qui etait attendu ...

je pars du principe d'une shared section, et du principe que le code dans la dll est aussi bien utilisable par un prog que par l'autre.

j'ai donc fait 3 executables : une dll contenant une classe contenant une variable, un exe changeant cette variable, et un exe la lisant.

header commun :

Code :

struct i_test
{
virtual int get() const = 0;
virtual void set(const int & ) = 0;
};

dll :

Code :

#include <windows.h>
#include <iostream>
#include "hdr.h"
#pragma section("myshared", shared)
class test : public i_test
{
int i;
public:
int get() const
{
return i;
}
void set(const int & var)
{
i = var;
}
};
__declspec(allocate("myshared" )) test shared_test;
i_test * WINAPI get_test()
{
return &shared_test;
}

(on lui fait exporter le symbole get_test)

programme changeant la variable :

Code :

#include <windows.h>
#include <iostream>
#include "../dlltest/hdr.h"
typedef i_test *(WINAPI*p_alloc_test)();
typedef i_test *(WINAPI*p_get_test)();
int main()
{
HMODULE hm = LoadLibrary("dlltest.dll" );
//p_alloc_test alloc_test = (p_alloc_test)GetProcAddress(hm, "alloc_test" );
p_get_test get_test = (p_get_test)GetProcAddress(hm, "get_test" );
i_test *t = get_test();
t->set(3);
MessageBox(NULL, "test->set(3);", "test_alloc", NULL);
FreeLibrary(hm);
}

programme lisant la variable :

Code :

#include <windows.h>
#include <iostream>
#include "../dlltest/hdr.h"
typedef i_test *(WINAPI*p_alloc_test)();
typedef i_test *(WINAPI*p_get_test)();
int main()
{
HMODULE hm = LoadLibrary("dlltest.dll" );
//p_alloc_test alloc_test = (p_alloc_test)GetProcAddress(hm, "alloc_test" );
p_get_test get_test = (p_get_test)GetProcAddress(hm, "get_test" );
i_test *t = get_test();
if(t->get() == 3)
MessageBox(NULL, "test->get() == 3;", "test_get", NULL);
else
MessageBox(NULL, "test->get() != 3;", "test_get", NULL);
FreeLibrary(hm);
}

(j'ai codé comme un cochon, c'etait juste pour voir si la solution que j'ai imaginé fonctionne)

---------------
-( BlackGoddess )-

blackgoddess

vive le troll !

sinon pour plus de dynamisme, il faudrait déclarer un buffer dans la mémoire partagée, et faire un allocateur/libérateur pour gérer ce buffer.

---------------
-( BlackGoddess )-

docmaboul

Taz a écrit :

ben c'est en simple ce que fait le placement de new. et ça fonctionne bien

c'est faux. Tout ce que fait un new placement, par défaut et qui n'a donc pas été surchargé, c'est :
inline void * operator new(size_t, void * p){return p;}

Taz

bisounours-codeur

DocMaboul a écrit :

c'est faux. Tout ce que fait un new placement, par défaut et qui n'a donc pas été surchargé, c'est :
inline void * operator new(size_t, void * p){return p;}

et ça n'est pas bien suffisant dans un cas simple ? franchement t'es lourd. tu sors connerie sur conneries, tu te le joues mais on voit rien de concret ... si y a bien quelqu'un de capable d'écire un allocateur ici, c'est moi. seulement, pas là peine de sortir le marteau pour écraser une mouche, d'autant plus que tout ça me parait une très mauvaise idée, je préfère à ce moment utiliser un processus proxy avec une petite zone de mémoire partagée servant de tampon de communication, ou utiliser les autres mécanismes classiques de communication inter-processus

docmaboul

BlackGoddess a écrit :

bon, j'ai trouvé une solution sous windows, je sais pas si c'est ce qui etait attendu ...

Non mais j'en suis responsable. Le problème est vieux et je l'ai très mal posé. Allez, la dernière mouture :

Soit une librairie dynamique tout ce qu'il y a de plus normale, comportant un bon gros millier de classes codées convenablement : à savoir sans saloperies comme les membres "static" et avec des allocateurs. Il y a des héritages entre ces classes et des jolies fonctions virtuelles à gogo. De plus, vous n'avez pas accès au code de la librairie. Quelle méthode utiliser pour pouvoir allouer les objets en shared memory et appeler les méthodes "normalement".

astuce 1: comme d'habitude, c'est faisable
astuce 2: la problématique se situe au niveau de la vtable des classes
astuce 3: on ne peut pas exécuter une fonction dont le code se trouve en shared avec la plupart des implémentations d'unix
astuce 4: si vous trouvez la seule méthode (à ma connaissance) clean, robuste et élégante, il y a peu de chance que vous puissiez l'implémenter

Taz

bisounours-codeur

1) ne pas allouer en mémoire partagée
2) ne pas allouer en mémoire partagée
3) ne pas allouer en mémoire partagée
4) ne pas allouer en mémoire partagée

5) me rappelez de ne plus jamais lire tes conneries

docmaboul

Taz a écrit :

Mais je suis toujours près à admettre que je me trompe. Aussi montre moi donc le code de ce new qui ferait cet interfaçage. Pour le reste, tu peux toujours me sortir l'implémentation de com, ça fait dix ans que ça existe.

edit: ou presque...

Message édité par docmaboul le 05-03-2004 à 16:29:04

docmaboul

Taz a écrit :

6) et faire un vi de new.h [:ambesanch]

blackgoddess

vive le troll !

DocMaboul a écrit :

avec des allocateurs.

bin l'allocateur de la lib va allouer sa mémoire a elle, dans l'espace du processus en cours, et aucun autre processus pourra la lire ...

sinon j'aurais dit recoder des allocateurs pour allouer sur un file mapping ...

ou sinon recoder un loader de librairie ...

Message édité par blackgoddess le 05-03-2004 à 16:39:39

---------------
-( BlackGoddess )-

docmaboul

BlackGoddess a écrit :

Je voulais dire par là que tu peux lui faire utiliser un ou des allocateurs et que les classes fonctionneront donc 'à peu près' correctement en shared si l'allocateur leur donne de la shared.

docmaboul

BlackGoddess a écrit :

ou sinon recoder un loader de librairie ...

Ca c'est intéressant. Pour quoi faire ?

blackgoddess

vive le troll !

et bien un loader de librairie, qui devra intercepter les appels systemes de réservation/libération de la mémoire et les rediriger vers un endroit ou la mémoire est partagée (refaire un allocateur, mais à plus bas niveau)

---------------
-( BlackGoddess )-

docmaboul

BlackGoddess a écrit :

Je suis déçu... Quelle problématique veux-tu résoudre ainsi ?

blackgoddess

vive le troll !

et bien, si toute l'utilisation mémoire de la librairie est ainsi gérée dans une zone partagée, les processus différents pourront y avoir accès ?

---------------
-( BlackGoddess )-

docmaboul

BlackGoddess a écrit :

et bien, si toute l'utilisation mémoire de la librairie est ainsi gérée dans une zone partagée, les processus différents pourront y avoir accès ?

Ce n'est pas compliqué d'obtenir l'accès au data se trouvant dans la mémoire partagée. La problématique vient des tables virtuelles des différentes classes (mais je ne te dis pas exactement pourquoi histoire que tu te creuses un peu le neurone :-).

bjone

Insert booze to continue

de quoi, que le pointeur à la table soit inconsistant entre les deux process ?

docmaboul

bjone a écrit :

de quoi, que le pointeur à la table soit inconsistant entre les deux process ?

grosso merdo : bingo !

blackgoddess

vive le troll !

qq1 m'explique o_O ?

---------------
-( BlackGoddess )-

docmaboul

BlackGoddess a écrit :

qq1 m'explique o_O ?

La vtable d'une classe est globale et commune à toutes les instances. Elle est adressée dans l'espace du créateur de l'objet et donc relativement à celui-ci, idem pour les fonctions qu'elle référence. Dans un autre process, il y a très peu de chance que tu aies les mêmes adresses => access violation dès que tu appelles une virtuelle.

bjone

Insert booze to continue

DocMaboul a écrit :

grosso merdo : bingo !

c'est cool, mais si tu avais mis un "virtual" devant ton toto, ça aurait été un peu plus évident.

si la méthode est pas virtual, ça pose pas de problèmes...
(malgré qu'il y ait des méthodes virtuelles)

Message édité par bjone le 05-03-2004 à 17:07:05

blackgoddess

vive le troll !

bien merci de l'explication

tu sais ou trouver une implémentation de ce truc ?

---------------
-( BlackGoddess )-

docmaboul

bjone a écrit :

c'est cool, mais si tu avais mis un "virtual" devant ton toto, ça aurait été un peu plus évident.

si la méthode est pas virtual, ça pose pas de problèmes...

C'est vrai et j'ai regretté d'avoir donné cet exemple qui n'était là que pour dire qu'en plus, je voulais une solution vraiment belle, c'est-à-dire sans un interfaçage à la mords-moi-le-com. Au lieu de clarifier, ça a embrouillé. Désolé.

docmaboul

BlackGoddess a écrit :

bien merci de l'explication

tu sais ou trouver une implémentation de ce truc ?

Je n'en connais pas d'implémentation open source, ni même licenciée.

bjone

Insert booze to continue

ceci dit, donc l'astuce ce serait quoi ?

d'utiliser un XXXX_cast<blabla> pour court-circuiter l'accès au pointeur vtable de l'instance ?

nope ça marcherai po des classes dérivée....

Message édité par bjone le 05-03-2004 à 17:13:17

docmaboul

bjone a écrit :

ceci dit, donc l'astuce ce serait quoi ?

Malheureusement, il n'y a pas d'astuce (ça se saurait).

Faut juste être complètement fou.

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

C++

Question pour un champion [1]

Sujets relatifs
2 petites question de rien du tout = pb email et HTML ... merci......	Question sur select()
petite question avec GTK	bonjour, est il possible de vous poser une question a propos de CSS ??
[JAVA] Question à propos des FlowLayout()	[C] Question sur strtol (conversion de char* en int)
[Visual C++] Question (basique) sur les CPen	Question Parsage avec SAX ...
[lisp] petite question sur implodech	Question pour un champion...
Plus de sujets relatifs à : Question pour un champion [1]

Page générée en 0.114 secondes