Demande d'avis et suggestions pour un problème d'implémentation

:salut:

Je travaille actuellement sur mon projets CStr. Pour faire court, c'est une bibliothèque de chaînes de caractères et à liaison dynamique (*.dll, *.so).

Pour l'améliorer, je cherche à faire une sorte de petit garbage collector ou du moins garder une trace de tous les objets créés dans une liste pour dans le cas probable d'une fin de programme les chaînes soient libérées (pour ce qui est du plantage d'un programme, je ne sais pas si cela pourra être géré).

Je me heurte cependant à un problème. Mes objets sont lié entre eux par le biais de pointeurs, comme si c'était des maillons d'une chaîne et tout comme on le ferais pour une liste. Je peut éventuellement créer une chaîne globale dont chaque nœuds seraient le départ d'une liste enfant (donc une suite d'objets CStr). Je pensais faire de cette manière car il faut que je prenne en compte une chose importante, c'est une bibliothèque partagée. De ce fait, je pensais récupérer le PID du processus en cours pour pouvoir injecter l'objet dans la bonne liste et surtout pour ne pas détruire tous les objets alors que plusieurs programmes en cours l'utilise, ce serait un peu embêtant sinon :aie:

Le crash du programme... De cette manière je ne pourrait pas le gérer mais je pense qu'il serait idiot de créer un programme séparé pour gérer le garbage collector juste pour des chaînes de caractères.

Je suppose que si le programme se termine anormalement, il n'est plus possible à la bibliothèque de vider correctement la liste que ce même processus utilisait et c'est bien ça mon petit problème, j'essaie de faire au mieux pour gérer au maximum et le plus efficacement la mémoire.

Voilà mon idée de base, je voulais avoir les avis et même des suggestions.

:merci:

Bonjour,

Êtes vous sur qu'une bibliothèque partagée, partage ses variables interne entre chaque programme ? Moi, j'en doute.
Ça voudrait dire, que si je veux hacker ton PC, je charge la bibliothèque Win32.dll (ou autre) et je scanne ses symboles :koi:. Peut être que je me trompe, mais ce que vous décrivez me semble bizarre.

Avec GCC, une bibliothèque peut avoir une fonction appelée avant le main et une après le main (init et fini). Ces fonctions doivent êtres déclarés avec des attribute, mais du moins cela existe et cela veut aussi dire que vous pouvez nettoyer le programme (bon, pas sur que ce soit le cas aussi, lors d'un crash :aie:).

Citation:

---

Envoyé par LittleWhite

Êtes vous sur qu'une bibliothèque partagée, partage ses variables interne entre chaque programme ? Moi, j'en doute.

---

Bin justement c'est une des questions que je me pose vu que je ne connais pas totalement le fonctionnement interne lors des appels a des bibliothèque de ce genre. Est-ce une instance différente par processus ?!?! il va de soi que cela me simplifierais le travail :mrgreen:

La mémoire allouée via une dll appartient au processus appelant.

Je vais essayer de ne pas dire de bêtise...
Mais il me semble "aussi" me souvenir de quelque chose comme quoi certaines libs ne sont chargées qu'une seule fois en mémoire.
Mais je crois que ça ne concerne que linux...

Mais il est vrai que chaque lib dynamique vit dans les images mémoire de chaque processus, indépendamment de chaque processus. (tortueux à dire et à comprendre)

Je crois que c'est le segment code qui n'est mappé qu'une seule fois en mémoire, et est ensuite partagé dans les autres AS qui ont besoin de la lib....
Mais les tas et pile sont "uniques" à chaque processus, donc les valeurs des mallocs et des locales peuvent varier sans problème.

Je ne suis pas sûr de moi, mais c'est un souvenir lointain d'un cours de kernel et de système qui me fait dire tout ça... (à vérifier donc)

Je pense que le meilleur moyen est que je ponde un programme de test que je fait tourner en x fois simultanément et que je test les valeurs. Le problème est que le comportement peut être différent suivant l'os mais je ne dispose que Windows :aie:

Citation:

---

Envoyé par Metalman

=Je crois que c'est le segment code qui n'est mappé qu'une seule fois en mémoire, et est ensuite partagé dans les autres AS qui ont besoin de la lib....
Mais les tas et pile sont "uniques" à chaque processus, donc les valeurs des mallocs et des locales peuvent varier sans problème.

---

C'est exact. Pour faire simple, seule la zone .text (le code) est partage entre processus. Les zones data (.bss, .stack, heap, ...) sont propres a chaque processus. Imagine le probleme sinon dans le cas de la libc par exemple... Pour rentrer plus dans le detail, en fait la zone .text de la lib partagee est mappee a de la memoire physique via la MMU lors de son premier chargement par un programme. Lors des chargements suivant de la lib partagee, le kernel n'alloue plus de memoire physique, mais projete la meme zone de memoire dans le nouveau process. Ca permet de ne charger qu'une fois le code en memoire physique si la bibilotheque est chargee 100 fois. Par contre, less zones donnees sont bien crees 100 fois.

Ainsi, les donnees d'un processus a un autre ne seront jamais exposees a un autre processus.

Pour en revenir au probleme initial, malloc fonctionne plus ou moins comme ta premiere solution (liste chainee + metada (taille,...)). Une simple liste chainee + metadonnees devrait suffire pour gerer ton GC.

Quant a l'arret du programme, tu dois pouvoir utiliser des destructors (via gcc __fini + linkage -lgcc) comme dit plus haut. Je pense pas qu'ils soient appelles en cas de crash (SIGSEGV et consort). A verifier.
Une idee est de gerer les signaux de crashs pour liberer la memoire proprement. Si ta bibliotheque est thread-safe (re-entrante), c'est complique.

Bon courage.

Mon blabla est surtout invérifiable sans lire les sources du noyau ! xD

Dans tous les cas, on est tous d'accord que votre DLL n'aura aucun "partage" de données entre processus.
Chaque processus aura son espace et ses strings, et RIEN de plus qui appartienne à un autre processus.

Contre-exemple pour appuyer ça (dans le même style que l'explication de LittleWhite) :
Si jamais l'utilisation de lib dynamique permettait un partage de mémoire entre processus... ça aurait été la toute nouvelle IPC encore plus efficace que toutes les autres : plus besoin de faire de la gestion de structures dans les read/write, et fini les file descriptors ! :P
En lisant shm_open (qui est apparemment la seule méthode partage de mémoire), on se rend compte que même elle renvoie un FD et nécessite pas mal de choses "juste" pour partager un objet en mémoire.

Bref : ne vous cassez pas la tête, la DLL est "unique" par processus au niveau de l'utilisation.

EDIT : dahtah a confirmé et BEAUCOUP développé EXACTEMENT ce que j'avais en souvenirs ! :P (le coup du mappage physique unique par la MMU)
Merci pour la confirmation !

Ok :merci: