“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 79 — #89
i
i
i
i
i
i
i
i
2.5 La gestion de mémoire
79
fun {Sum X L1}
case L1 of Y|L2 then {Sum X+Y L2} else X end
end
{Browse {Sum 0 L}}
Ici la référence à L est perdue immédiatement. Cet exemple est trivial. Mais les choses
peuvent être plus subtiles. Par exemple, considérez une structure de données active
S qui contient une liste d’autres structures de données D1, D2, . . . , Dn. Si une de
celles-là, disons Di, n’est plus utilisée par le programme, alors elle devra être enlevée
de la liste. Sinon sa mémoire ne sera jamais récupérée.
Un programme bien écrit doit donc faire un peu de « nettoyage » de temps en temps,
pour être sûr qu’il ne référence plus les structures de données dont il n’a plus besoin.
Ce nettoyage est possible dans le modèle déclaratif, mais il est encombrant à faire
pour le programmeur.
11
Gérer les ressources externes
Un programme Mozart a souvent besoin de structures de données qui sont externes
à son processus dans le système d’exploitation. Nous appelons une telle structure
de données une ressource externe. Les ressources externes influent sur la gestion de
mémoire en deux manières. Une structure de données interne à Mozart peut référencer
une ressource externe et vice versa. Les deux possibilités demandent une intervention
du programmeur. Considérons chaque cas séparément.
Premier cas : une structure de données Mozart référence une ressource externe. Par
exemple, un enregistrement peut correspondre à une entité graphique sur un affichage
graphique ou un fichier ouvert dans un système de fichiers. Si l’enregistrement n’est
plus utilisé, alors l’entité graphique devra être enlevée ou le fichier devra être fermé.
Sinon, l’affichage graphique ou le système de fichiers aura une fuite de mémoire.
Le nettoyage est fait avec une technique qui s’appelle la finalisation, qui définit les
actions à faire quand les structures de données disparaissent. La finalisation est hors
de notre propos.
12
Deuxième cas : une ressource externe a besoin d’une structure de données Mozart.
C’est parfois facile à traiter. Par exemple, considérons un scénario où le programme
Mozart implémente un serveur de base de données qui est appelé par des clients
externes. Ce scénario a une solution simple : ne jamais faire de la récupération automatique de la mémoire de la base de données. D’autres scénarios ne sont pas toujours
aussi simples. Une solution générale est de mettre de côté une partie du programme
Mozart pour représenter la ressource externe. Cette partie doit être active (c’est-à-dire
avoir son propre fil) pour qu’elle ne soit pas récupérée au hasard. Elle peut être vue
11. Il est plus simple de le faire avec l’état explicite (voir chapitre 5).
12. La finalisation est expliquée dans [97].
© Dunod – La photocopie non autorisée est un délit
i
i
i
i
i
i
i
i
2.5 La gestion de mémoire
79
fun {Sum X L1}
case L1 of Y|L2 then {Sum X+Y L2} else X end
end
{Browse {Sum 0 L}}
Ici la référence à L est perdue immédiatement. Cet exemple est trivial. Mais les choses
peuvent être plus subtiles. Par exemple, considérez une structure de données active
S qui contient une liste d’autres structures de données D1, D2, . . . , Dn. Si une de
celles-là, disons Di, n’est plus utilisée par le programme, alors elle devra être enlevée
de la liste. Sinon sa mémoire ne sera jamais récupérée.
Un programme bien écrit doit donc faire un peu de « nettoyage » de temps en temps,
pour être sûr qu’il ne référence plus les structures de données dont il n’a plus besoin.
Ce nettoyage est possible dans le modèle déclaratif, mais il est encombrant à faire
pour le programmeur.
11
Gérer les ressources externes
Un programme Mozart a souvent besoin de structures de données qui sont externes
à son processus dans le système d’exploitation. Nous appelons une telle structure
de données une ressource externe. Les ressources externes influent sur la gestion de
mémoire en deux manières. Une structure de données interne à Mozart peut référencer
une ressource externe et vice versa. Les deux possibilités demandent une intervention
du programmeur. Considérons chaque cas séparément.
Premier cas : une structure de données Mozart référence une ressource externe. Par
exemple, un enregistrement peut correspondre à une entité graphique sur un affichage
graphique ou un fichier ouvert dans un système de fichiers. Si l’enregistrement n’est
plus utilisé, alors l’entité graphique devra être enlevée ou le fichier devra être fermé.
Sinon, l’affichage graphique ou le système de fichiers aura une fuite de mémoire.
Le nettoyage est fait avec une technique qui s’appelle la finalisation, qui définit les
actions à faire quand les structures de données disparaissent. La finalisation est hors
de notre propos.
12
Deuxième cas : une ressource externe a besoin d’une structure de données Mozart.
C’est parfois facile à traiter. Par exemple, considérons un scénario où le programme
Mozart implémente un serveur de base de données qui est appelé par des clients
externes. Ce scénario a une solution simple : ne jamais faire de la récupération automatique de la mémoire de la base de données. D’autres scénarios ne sont pas toujours
aussi simples. Une solution générale est de mettre de côté une partie du programme
Mozart pour représenter la ressource externe. Cette partie doit être active (c’est-à-dire
avoir son propre fil) pour qu’elle ne soit pas récupérée au hasard. Elle peut être vue
11. Il est plus simple de le faire avec l’état explicite (voir chapitre 5).
12. La finalisation est expliquée dans [97].
© Dunod – La photocopie non autorisée est un délit