IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

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


Sujet :

C

  1. #1
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Points : 12 462
    Points
    12 462
    Par défaut Demande d'avis et suggestions pour un problème d'implémentation


    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

    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.

    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

  2. #2
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    26 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2008
    Messages : 26 826
    Points : 218 287
    Points
    218 287
    Billets dans le blog
    117
    Par défaut
    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 . 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 ).
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  3. #3
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Points : 12 462
    Points
    12 462
    Par défaut
    Citation Envoyé par LittleWhite Voir le message
    Ê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
    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

  4. #4
    CGi
    CGi est déconnecté
    Expert éminent
    Avatar de CGi
    Inscrit en
    Mars 2002
    Messages
    1 026
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 1 026
    Points : 8 311
    Points
    8 311
    Par défaut
    La mémoire allouée via une dll appartient au processus appelant.
    Site : http://chgi.developpez.com

    Pourquoi faire simple quand on peut faire compliqué ? (Jacques Rouxel)

  5. #5
    Membre expert
    Avatar de Metalman
    Homme Profil pro
    Enseignant-Chercheur
    Inscrit en
    Juin 2005
    Messages
    1 049
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Enseignant-Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 049
    Points : 3 532
    Points
    3 532
    Par défaut
    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)
    --
    Metalman !

    Attendez 5 mins après mes posts... les EDIT vont vite avec moi...
    Les flags de la vie : gcc -W -Wall -Werror -ansi -pedantic mes_sources.c
    gcc -Wall -Wextra -Werror -std=c99 -pedantic mes_sources.c
    (ANSI retire quelques fonctions comme strdup...)
    L'outil de la vie : valgrind --show-reachable=yes --leak-check=full ./mon_programme
    Et s'assurer que la logique est bonne "aussi" !

    Ma page Developpez.net

  6. #6
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Points : 12 462
    Points
    12 462
    Par défaut
    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
    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

  7. #7
    Membre éclairé
    Profil pro
    Ingénieur sécurité
    Inscrit en
    Février 2007
    Messages
    574
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur sécurité
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2007
    Messages : 574
    Points : 751
    Points
    751
    Par défaut
    Citation Envoyé par Metalman Voir le message
    =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.

  8. #8
    Membre expert
    Avatar de Metalman
    Homme Profil pro
    Enseignant-Chercheur
    Inscrit en
    Juin 2005
    Messages
    1 049
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Enseignant-Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 049
    Points : 3 532
    Points
    3 532
    Par défaut
    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 !
    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 ! (le coup du mappage physique unique par la MMU)
    Merci pour la confirmation !
    --
    Metalman !

    Attendez 5 mins après mes posts... les EDIT vont vite avec moi...
    Les flags de la vie : gcc -W -Wall -Werror -ansi -pedantic mes_sources.c
    gcc -Wall -Wextra -Werror -std=c99 -pedantic mes_sources.c
    (ANSI retire quelques fonctions comme strdup...)
    L'outil de la vie : valgrind --show-reachable=yes --leak-check=full ./mon_programme
    Et s'assurer que la logique est bonne "aussi" !

    Ma page Developpez.net

  9. #9
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Points : 12 462
    Points
    12 462
    Par défaut
    Ok
    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

Discussions similaires

  1. Demande d'avis et conseils pour choisir SGBD
    Par Ceddoc dans le forum Décisions SGBD
    Réponses: 10
    Dernier message: 18/01/2012, 12h38
  2. Demande d'avis sur prix pour petit site
    Par cuisto44000 dans le forum Devis
    Réponses: 11
    Dernier message: 23/08/2010, 23h56
  3. Demande de conseils pour divers problèmes
    Par lilyla dans le forum MATLAB
    Réponses: 2
    Dernier message: 21/05/2007, 12h38
  4. Réponses: 2
    Dernier message: 11/04/2007, 22h59
  5. Demande d'avis pour projet
    Par aerosim dans le forum WinDev
    Réponses: 9
    Dernier message: 21/06/2006, 11h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo