Ce n'est vraiment pas un problème spécifique à shm, au contraire !
Car cette obligation s'applique à toutes les zonnes mémoires allouées dynamiquement par tout process et tout thread. Et même dans le cas d'un processus monothread isolé. Il faut toujours s'assurer qu'aucun objet que l'on utilise ne se trouve dans une zone avant de la libérer par free !
Et si on ne veut pas se faire chier, il n'y a que la solution de la libération automatique à la mort du process (ou des process dans le cas de shm).
Avec les threads tu dois faire ce travail aussi. Et même encore + !
Totalement faux.
Dans les 2 cas, tu dois t'assurer que tu n'utilises vraiment plus la memoire avant de faire un free(free reel dans le cas multithread, wrapper free dans le cas shm)
Mais en plus dans le cas shm tu dois suivre toutes les allocations pour savoir quand le segment complet peut etre detache, car pour les threads, la heap fait ca pour toi.
Bref :
threads : alloues et liberes buffer avec malloc/free, et la heap se charge de savoir quand les gros blocs qu'elle alloue peuvent etre liberes vu qu'elle fait son propre resource tracking.
shm: alloues et libere les buffers dans le segment avec un malloc/free proprio qui doit faire le resource tracking a la place de la heap pour savoir quand le segment peut etre desalloue.
Dans le 2eme cas tu es clairement oblige de faire ton propre resource tracking vu que tu peux pas utiliser la heap d'origine pour ca.
Serieusement, j'ai assez d'experience avec les 2 architectures pour savoir que la methode segments partages n'est tout simplement pas une solution de remplacement viable en general pour les threads, ca peut etre utile dans certains cas mais c'est tres tres loin d'etre le cas generalement.
[^] # Re: malloc bugs pour threads
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Car cette obligation s'applique à toutes les zonnes mémoires allouées dynamiquement par tout process et tout thread. Et même dans le cas d'un processus monothread isolé. Il faut toujours s'assurer qu'aucun objet que l'on utilise ne se trouve dans une zone avant de la libérer par free !
Et si on ne veut pas se faire chier, il n'y a que la solution de la libération automatique à la mort du process (ou des process dans le cas de shm).
Avec les threads tu dois faire ce travail aussi. Et même encore + !
Totalement faux.
Dans les 2 cas, tu dois t'assurer que tu n'utilises vraiment plus la memoire avant de faire un free(free reel dans le cas multithread, wrapper free dans le cas shm)
Mais en plus dans le cas shm tu dois suivre toutes les allocations pour savoir quand le segment complet peut etre detache, car pour les threads, la heap fait ca pour toi.
Bref :
threads : alloues et liberes buffer avec malloc/free, et la heap se charge de savoir quand les gros blocs qu'elle alloue peuvent etre liberes vu qu'elle fait son propre resource tracking.
shm: alloues et libere les buffers dans le segment avec un malloc/free proprio qui doit faire le resource tracking a la place de la heap pour savoir quand le segment peut etre desalloue.
Dans le 2eme cas tu es clairement oblige de faire ton propre resource tracking vu que tu peux pas utiliser la heap d'origine pour ca.
Serieusement, j'ai assez d'experience avec les 2 architectures pour savoir que la methode segments partages n'est tout simplement pas une solution de remplacement viable en general pour les threads, ca peut etre utile dans certains cas mais c'est tres tres loin d'etre le cas generalement.