Oui, enfin quand une application est en train de construire une représentation mémoire d’un svg dans l’espoir de l’afficher, on peut supposer qu’elle utilise une bonne part du CPU et qu’elle réalise la majorité des mallocs à ce moment là
Donc il n'y à aucune raison que l'OOM killer ne soit pas capable de définir une heuristique qui retrouve ce processus. Pour avoir un peu suivi les discutions sur l'OOM killer il y a quelques années, c'est visiblement pas si simple (le coup de shooter le processus qui à fait le plus d'alloc dans les dernières secondes a été testé, tout comme le plus gros et des dizaines de variantes).
Enfin, c’est la base… si un développeur ne sait pas gérer un malloc qui échoue, il devrait apprendre.
Il y a une différence entre la théorie et la pratique dans des vraies applis complexes. Et souvent la complexité ajoutée par gérer spécifiquement ce cas, fait que ca ne vaut pas le coup par rapport à un suicide simple. Ce type d'erreur peut facilement cascader et empêcher de faire toute chose utile ou même de notifier l'utilisateur que tu ne peux pas faire ce qu'il demande. À quoi bon tout saloper pour le même résultat au final ? Au pire tu vas même introduire des inconsistances à cause de ton code de rattrapage.
Et la on ne parle que du C. Dans la plupart des langages modernes tout le monde se balance de ce cas. J'ai jamais vu catcher des ErrorMemory, OutOfMemoryException ou je ne sais même pas quoi en js sauf dans des cas bien particuliers. Et vu que les libs ne le font pas non plus, tu pourrais wrapper chaque appel de méthode aussi.
Après ce n'est pas vrai pour tout. Il y a des cas où c'est faisable et à faire. Mais si tu tests avec les applis de ton desktop j'ai une petite idée du résultat.
[^] # Re: Malloc Linux
Posté par ckyl . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 4. Dernière modification le 21 mai 2013 à 18:32.
Donc il n'y à aucune raison que l'OOM killer ne soit pas capable de définir une heuristique qui retrouve ce processus. Pour avoir un peu suivi les discutions sur l'OOM killer il y a quelques années, c'est visiblement pas si simple (le coup de shooter le processus qui à fait le plus d'alloc dans les dernières secondes a été testé, tout comme le plus gros et des dizaines de variantes).
Il y a une différence entre la théorie et la pratique dans des vraies applis complexes. Et souvent la complexité ajoutée par gérer spécifiquement ce cas, fait que ca ne vaut pas le coup par rapport à un suicide simple. Ce type d'erreur peut facilement cascader et empêcher de faire toute chose utile ou même de notifier l'utilisateur que tu ne peux pas faire ce qu'il demande. À quoi bon tout saloper pour le même résultat au final ? Au pire tu vas même introduire des inconsistances à cause de ton code de rattrapage.
Et la on ne parle que du C. Dans la plupart des langages modernes tout le monde se balance de ce cas. J'ai jamais vu catcher des ErrorMemory, OutOfMemoryException ou je ne sais même pas quoi en js sauf dans des cas bien particuliers. Et vu que les libs ne le font pas non plus, tu pourrais wrapper chaque appel de méthode aussi.
Après ce n'est pas vrai pour tout. Il y a des cas où c'est faisable et à faire. Mais si tu tests avec les applis de ton desktop j'ai une petite idée du résultat.