Arcruxe a écrit 13 commentaires

Le cache du noyau n'est plus utilisé pour les disques en ZFS si je ne dit pas de bêtise. Pour info, unifier l'ARC de ZFS et le pagecache de Linux fait partie de la todolist du projet ZFS on Linux.

Et si jamais ne peut pas réparer (zpool non redondant par exemple), il donne la liste des fichiers touchés pour qu'on puisse les restaurer depuis une backup :)

C'est pas tout à fait aussi simple que ça. Le disque dur doit en plus posséder une intelligence au niveau bloc (au minimum). Si tu fais du sync brut de fonderie tu vas à la catastrophe, si tu fais du sync en mode pur synchrone tu tues les perfs.

Pour info, ZFS s'occupe aussi de cette partie, d'ailleurs quand on donne un disque complet à un zpool et non une partition, il met le scheduler io du noyau sur "noop" pour utiliser le sien à la place.
Il faudrait comparer les performances du scheduler de ZFS et ceux des fabriquants de disques dur sur différents workload pour savoir qui est le plus efficace :)

Et l'option -o ashift=12 à la commande zpool sous Linux.

Attention, en plus d'à la création du pool (zpool create), il faut aussi l'utiliser avec zpool add quand on ajoute un top-level vdev au pool, sinon le nouveau top-level vdev aura la valeur par défaut (9).

idem :)

Je préfère que le programme plante, histoire de ne pas avoir un état incohérent, et que le couillon qui gère l'administration du produit ne se dise pas que ce n'est qu'un « warning ».

Donc a priori la solution qui te plairait le mieux ça serait de donner un "handler" (pointeur de fonction ou foncteur) à l'objet, qu'il peut appeler en cas d'erreurs sur une tâche asynchrone (voir mon autre post).

D'ailleurs, par durée de vie du programme, tu entends une variable statique instanciée lors de la création du process (et donc un comportement indéfini à la clé) ?

Pas nécessairement non.
Et d'ailleurs une variable static globale n'est pas un comportement indéfini, il faut juste être très prudent quand on en utilise (j'évite toujours personnellement).

Le problème n'est pas le nombre d'exceptions à gérer, mais le fait que la destruction d'un objet est suspendue par la levée de l'exception, et qu'on se retrouve alors avec un objet partiellement détruit, ce qui pose des problèmes de fiabilité.

C'est bien pour ça que c'est au destructeur de faire quelque chose d'approprié quand il rencontre un problème, au lieu de lèver une exception / en laisser une se propager à l'appelant.

Et du point de vue du fonctionnement du langage, c'est effectivement de se retrouver avec deux exceptions à gérer en même temps qui est problématique.
http://www.parashift.com/c++-faq/dtors-shouldnt-throw.html

Une autre façon de voir les choses : une fonction doit lever une exception si et seulement si ses post-conditions ne peuvent pas être remplies. L'unique post-condition d'un destructeur est que l'objet n'existe plus en mémoire. Cette post-condition est toujours remplie quoi qu'il arrive. Donc un destructeur ne peut jamais légitimement lever d'exceptions.

Non, l'exception n'est pas lancée dans le destructeur. Elle est lancée indirectement depuis le destructeur.

Tu pinailles, ça revient exactement au même…

Maintenant, je m'attendais à ce que tu vienne avec une solution qui est encore pire qu'un segfault : attraper l'exception dans le destructeur, et continuer comme si de rien n'était (oui, cracher dans std::cerr revient à ne rien faire).

Voir mon autre post en réponse à ckyl.

Premièrement, parce qu'on ne sait pas dans quel état on est

De mon point de vue, c'est justement le travail du destructeur de faire quelque chose d'approprié quand il lève une exception. Justement pour avoir un état valide à la fin. Et, si ce n'est pas possible, appeler std::terminate dans le destructeur est acceptable. Une autre solution pas trop mal, c'est de donner un "handler" à l'objet (pointeur de fonction / foncteur), qu'il peut appeler en cas d'erreurs sur une tâche asynchrone (y compris dans le destructeur). Comme ça, le programme peut faire ce qui lui semble approprié dans ce cas (et il est certainement mieux placé que le destructeur peut savoir ce qui est "le mieux" à faire d'ailleurs).

C'est d'ailleurs pour ça que le programme se termine quand une exception est balancée depuis un destructeur : c'est la panique.

Non, ton exemple s'est retrouvé dans std::terminate parce qu'une exception n'a pas été attrapée : l'exception lancée dans le destructeur de l'objet du premier morceau de code du main, après le catch (celui qui affiche "Catched exception"). Le deuxième morceau de code du main n'est, par conséquent, pas exécute (s'il était, le catch serait exécuté comme attendu et "That can't be catched" serait affiché sur la sortie standard).
Appeler flush et close explicitement dans l'appelant ne résout pas le problème…

Oui c'est vachement mieux de jeter ca sous le tapis ni vu ni connu ;)

J'ai pas non plus dit de jeter ça sous le tapis… Mon exemple affiche un message d'erreur. On peut aussi écrire un truc dans un fichier de log, envoyer un mail à la supervision, appeler std::terminate soi-même, etc. Il y a de nombreuses solutions, mais aucune n'est vraiment satisfaisante. La meilleure chose, c'est encore de faire en sorte de pas avoir d'erreurs à gérer (ou le moins possible) dans les destructeurs. Donc éviter les traitements trop complexes. Si on a besoin d'en faire, à mon humble avis, c'est qu'on a un problème d'architecture dans le programme…

Par exemple si je reprends l'exemple de l'écriture fainéante, on peut faire un singleton (qui a la même durée de vie que le programme) qui s'occupe de gérer tous les fichiers ouverts et de les flusher quand nécessaire. Ou alors (et à mon avis c'est encore le mieux pour cet exemple) on fait pas d'écriture fainéante dans notre programme et on laisse l'ordonnanceur d'entrées/sorties du noyau faire son boulot.
Pour être honnête, je trouve ça vraiment gênant cette histoire d'écriture fainéante, puisque quoi qu'il arrive, on ne peut pas remonter les erreurs à l'appelant au bon moment.
On peut aussi considérer que ça fait partie de la sémantique de la classe : les écritures peuvent échouer sans pour autant remonter d'erreurs… Auquel cas l'appelant doit en être parfaitement conscient et architecturer son code en conséquence.

Ou sinon il faut expliquer à Bjarne Stroustrup que lancer des exceptions dans un destructeur c'est bien et que c'est pas grave de pouvoir se retrouver avec deux exceptions à gérer en même temps ou autre joyeuseté…

Ton destructeur balance une exception, évidemment que ça se passe mal, il ne faut jamais lancer d'exceptions dans un destructeur.
Si tu veux vraiment laisser le fonctionnement de ta classe tel quel (c'est-à-dire écriture fainéante), tu dois par exemple attraper l'exception de flush dans ton destructeur :

        ~file()
        {
            try {
                flush();
                close();
            } catch(my_ns::io_error const & e) {
                std::cerr << "destruction failure!\n";
            }
        }

http://www.stroustrup.com/bs_faq2.html#ctor-exceptions

Le problème c'est pas RAII, c'est que tu lances une exception dans le destructeur…

Et je te renverrai au « Exceptional C++ » de Herb Sutter, qui conseille fortement de libérer une ressource avant de sortir du scope.

Je n'ai pas ce livre, donc si tu pouvais étayer un peu ton propos histoire que je comprenne où tu veux en venir…

Évidement, la ressource devrait être correctement libérée en cas d'exception, mais dans le cas où aucune exception n'est levée il est tout indiqué de libérer la ressource inutile, pour éviter qu'une exception ne soit lever dans un destructeur.

Je ne vois pas ce que les destructeurs viennent faire dans l'histoire, et encore moins d'où sortirais la fameuse exception qu'il leverait…
Sans le f.close(), la ressource est correctement libérée, qu'il y ait une exception ou pas, puisque le destructeur va s'en charger.

http://www.stroustrup.com/bs_faq2.html#finally

Le mot-clef finally a été introduit, permettant de combler un manque dans PHP par rapport à d'autres langages comme C++, Java ou Python.

"finally" n'existe pas en C++, et il n'y en a pas besoin, vive RAII :)
En revanche il me semble que Microsoft l'a rajouté dans son C++ version .NET…

Le support de TRIM/discard pour les SSD dans md (RAID) avait été intégré pendant la merge window (voir http://lwn.net/Articles/519515/). À moins qu'ils n'aient été retiré pendant la phase de rc, ce noyau 3.7 supporte TRIM pour les volumes RAID :)