Ton approche est intéressante, mais après réflexion elle va n'être pertinente que dans le cas que tu décris : un soft qui fait éventuellement des grosses allocations pendant pas longtemps. Effectivement, les autres à côté peuvent patienter un peu jusqu'à la RAM soit libérée.
Mais imaginons un autre cas. Ta technique se répand, tous les softs s'y mettent. Sur un serveur, on a par un exemple un serveur web qui lance un processus par connexion. Chaque processus consomme pas grand chose, mais consomme régulièrement. Il y a beaucoup de connexion, on commence à toucher les limites en terme d'allocation mémoire :
- système "classique" qui segfaulte ou aborte : le processus qui va vouloir franchir la limite va claquer, ce qui va libérer un peu de RAM pour les autres qui vont continuer. Si d'autres connexions arrivent, le système va certes tuer quelques processus, mais il en fera toujours tourner à la limite de ses capacités.
- ton système : le processus qui va franchir la limite va partir en boucle infinie, les autres qui continuent d'allouer un peu vont aussi partir en boucle infinie. Un bon gros dead lock en somme.
Ceci dit, je suis parfaitement d'accord avec ça :
Perso c'est simple, je considère que ne pas gèrer un NULL retourné par malloc est une faute grave si malloc peut retourner NULL.
Mais en C je vois pas comment faire sans utiliser la méthode canonique qui consiste à vérifier le retour de malloc() à chaque appel et avoir architecturé le soft pour qu'il soit capable de gérer un NULL proprement.
[^] # Re: Approche hybride
Posté par guppy . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 3.
Ton approche est intéressante, mais après réflexion elle va n'être pertinente que dans le cas que tu décris : un soft qui fait éventuellement des grosses allocations pendant pas longtemps. Effectivement, les autres à côté peuvent patienter un peu jusqu'à la RAM soit libérée.
Mais imaginons un autre cas. Ta technique se répand, tous les softs s'y mettent. Sur un serveur, on a par un exemple un serveur web qui lance un processus par connexion. Chaque processus consomme pas grand chose, mais consomme régulièrement. Il y a beaucoup de connexion, on commence à toucher les limites en terme d'allocation mémoire :
- système "classique" qui segfaulte ou aborte : le processus qui va vouloir franchir la limite va claquer, ce qui va libérer un peu de RAM pour les autres qui vont continuer. Si d'autres connexions arrivent, le système va certes tuer quelques processus, mais il en fera toujours tourner à la limite de ses capacités.
- ton système : le processus qui va franchir la limite va partir en boucle infinie, les autres qui continuent d'allouer un peu vont aussi partir en boucle infinie. Un bon gros dead lock en somme.
Ceci dit, je suis parfaitement d'accord avec ça :
Mais en C je vois pas comment faire sans utiliser la méthode canonique qui consiste à vérifier le retour de malloc() à chaque appel et avoir architecturé le soft pour qu'il soit capable de gérer un NULL proprement.