Existe-t-il des fonctions standards ( par exemple fermer un
fichier) qui peuvent - être exécuter si:
il y a panne de courant ... , j'en doute
on ferme l'ordinateur (genre pesez sur ce bouton pour fermer
l'ordnateur)
on lance un autre processus pour tuer notre application...
Merci de votre attention.
Jean Pierre Daviau
--
C l'histoire de fumer une dernière cigarette avant de mourir du
cancer du poumon.
windows Xp
asus p4 s533/333/133
Intel(R) Celeron (R) CPU 2.00 GHz
Processor Radeon7000 0x5159 agp
Lorsqu'un malheureux étudiant faisait un reboot, le code de calcul recevait le signal, dumpait les données, et... laissait la machine rebooter tranquilement.
J'oubliais ce cas là aussi.
Lorsqu'un malheureux étudiant faisait un reboot, le code de
calcul
recevait le signal, dumpait les données, et... laissait la
machine
rebooter tranquilement.
Lorsqu'un malheureux étudiant faisait un reboot, le code de calcul recevait le signal, dumpait les données, et... laissait la machine rebooter tranquilement.
J'oubliais ce cas là aussi.
Antoine Leca
Jean Pierre Daviau wrote:
Existe-t-il des fonctions standards ( par exemple fermer un fichier) qui peuvent - être exécuter si: il y a panne de courant on ferme l'ordinateur
Si par « standard » tu penses « autorisé pour une programme strictement conforme dans le cadre de la norme », la réponse est non : la norme ne définit qu'un sous-ensemble des programmes possibles, pour permettre la plus grande portabilité ; et la gestion de ce genre d'événements n'est pas complètement portable (cela n'a pas exactement la même signification sur un mainframe que sur un anti-blocage de roues.)
Sinon, en plus général et moins standard, il y a atexit() et ses variantes (mais il y a des chances que cela soit court-circuité en cas d'exceptions, justement), ou l'interception des signaux à la mode Unix, qui permet de définir des comportements différents dans les cas ci-dessus (SIGPWRDWN, SIGTERM ou SIGKILL), et qui _peuvent_ te permettre de lancer des appels noyau aussi complexes que fermer_un_fichier ou mieux écrire DQP les données sur disque, sync(2).
<ÉLUCUBRATIONS>
on lance un autre processus pour tuer notre application...
Euh là, c'est de la prémonition, si tu veux que l'ordinateur avertisse lorsque tu _lances_ en parallèle un nouveau processus (dans lequel, ultérieurement, sera émis un ordre de meutre.) Tu veux que le noyau émette un avertissement lorsque un nom de programme inclut "Kill", un peu comme le système de Vista qui donne des droits spéciaux aux programmes qui s'appellent "Setup" ou "Install" ? </ÉLUCUBRATIONS>
Antoine
Jean Pierre Daviau wrote:
Existe-t-il des fonctions standards ( par exemple fermer un
fichier) qui peuvent - être exécuter si:
il y a panne de courant
on ferme l'ordinateur
Si par « standard » tu penses « autorisé pour une programme strictement
conforme dans le cadre de la norme », la réponse est non : la norme ne
définit qu'un sous-ensemble des programmes possibles, pour permettre la plus
grande portabilité ; et la gestion de ce genre d'événements n'est pas
complètement portable (cela n'a pas exactement la même signification sur un
mainframe que sur un anti-blocage de roues.)
Sinon, en plus général et moins standard, il y a atexit() et ses variantes
(mais il y a des chances que cela soit court-circuité en cas d'exceptions,
justement), ou l'interception des signaux à la mode Unix, qui permet de
définir des comportements différents dans les cas ci-dessus (SIGPWRDWN,
SIGTERM ou SIGKILL), et qui _peuvent_ te permettre de lancer des appels
noyau aussi complexes que fermer_un_fichier ou mieux écrire DQP les données
sur disque, sync(2).
<ÉLUCUBRATIONS>
on lance un autre processus pour tuer notre application...
Euh là, c'est de la prémonition, si tu veux que l'ordinateur avertisse
lorsque tu _lances_ en parallèle un nouveau processus (dans lequel,
ultérieurement, sera émis un ordre de meutre.) Tu veux que le noyau émette
un avertissement lorsque un nom de programme inclut "Kill", un peu comme le
système de Vista qui donne des droits spéciaux aux programmes qui
s'appellent "Setup" ou "Install" ?
</ÉLUCUBRATIONS>
Existe-t-il des fonctions standards ( par exemple fermer un fichier) qui peuvent - être exécuter si: il y a panne de courant on ferme l'ordinateur
Si par « standard » tu penses « autorisé pour une programme strictement conforme dans le cadre de la norme », la réponse est non : la norme ne définit qu'un sous-ensemble des programmes possibles, pour permettre la plus grande portabilité ; et la gestion de ce genre d'événements n'est pas complètement portable (cela n'a pas exactement la même signification sur un mainframe que sur un anti-blocage de roues.)
Sinon, en plus général et moins standard, il y a atexit() et ses variantes (mais il y a des chances que cela soit court-circuité en cas d'exceptions, justement), ou l'interception des signaux à la mode Unix, qui permet de définir des comportements différents dans les cas ci-dessus (SIGPWRDWN, SIGTERM ou SIGKILL), et qui _peuvent_ te permettre de lancer des appels noyau aussi complexes que fermer_un_fichier ou mieux écrire DQP les données sur disque, sync(2).
<ÉLUCUBRATIONS>
on lance un autre processus pour tuer notre application...
Euh là, c'est de la prémonition, si tu veux que l'ordinateur avertisse lorsque tu _lances_ en parallèle un nouveau processus (dans lequel, ultérieurement, sera émis un ordre de meutre.) Tu veux que le noyau émette un avertissement lorsque un nom de programme inclut "Kill", un peu comme le système de Vista qui donne des droits spéciaux aux programmes qui s'appellent "Setup" ou "Install" ? </ÉLUCUBRATIONS>
Antoine
ALain Montfranc
Jean Pierre Daviau a écrit
Bonjour à tous,
Existe-t-il des fonctions standards ( par exemple fermer un fichier) qui peuvent - être exécuter si: il y a panne de courant ... , j'en doute on ferme l'ordinateur (genre pesez sur ce bouton pour fermer l'ordnateur) on lance un autre processus pour tuer notre application...
Merci de votre attention.
Jean Pierre Daviau
Pour la panne de courant, tu mets un onduleur un peu intelligent et tu es ramené au pb "extinction propre de la machine"
Jean Pierre Daviau a écrit
Bonjour à tous,
Existe-t-il des fonctions standards ( par exemple fermer un fichier) qui
peuvent - être exécuter si:
il y a panne de courant ... , j'en doute
on ferme l'ordinateur (genre pesez sur ce bouton pour fermer l'ordnateur)
on lance un autre processus pour tuer notre application...
Merci de votre attention.
Jean Pierre Daviau
Pour la panne de courant, tu mets un onduleur un peu intelligent et tu
es ramené au pb "extinction propre de la machine"
Existe-t-il des fonctions standards ( par exemple fermer un fichier) qui peuvent - être exécuter si: il y a panne de courant ... , j'en doute on ferme l'ordinateur (genre pesez sur ce bouton pour fermer l'ordnateur) on lance un autre processus pour tuer notre application...
Merci de votre attention.
Jean Pierre Daviau
Pour la panne de courant, tu mets un onduleur un peu intelligent et tu es ramené au pb "extinction propre de la machine"
Xavier Roche
Sinon, en plus général et moins standard, il y a atexit() et ses variantes (mais il y a des chances que cela soit court-circuité en cas d'exceptions, justement)
Et une bonne panne de courant sans onduleur est de toute manière fatale.
En général, on ne se pose pas ce genre de question: on est capable de prévoir des bases de données capables de récupérer le dernier état consistent, même après une panne brutale d'alimentation (par exemple, arrachage du câble d'alimentation).
Cela veut dire des fonctions comme fdatasync/fsync (POSIX ; <http://www.opengroup.org/onlinepubs/007908799/xsh/fdatasync.html> et <http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html>) qui permettent d'être _sûr_ que, après le retour de la fonction, le fichier a bien été écrit _physiquement_ sur disque (c'est à dire que le disque a lui même propagé l'écriture sur les plateaux, et pas uniquement dans sa mémoire write-back)
Sinon, en plus général et moins standard, il y a atexit() et ses variantes
(mais il y a des chances que cela soit court-circuité en cas d'exceptions,
justement)
Et une bonne panne de courant sans onduleur est de toute manière fatale.
En général, on ne se pose pas ce genre de question: on est capable de
prévoir des bases de données capables de récupérer le dernier état
consistent, même après une panne brutale d'alimentation (par exemple,
arrachage du câble d'alimentation).
Cela veut dire des fonctions comme fdatasync/fsync (POSIX ;
<http://www.opengroup.org/onlinepubs/007908799/xsh/fdatasync.html> et
<http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html>) qui
permettent d'être _sûr_ que, après le retour de la fonction, le fichier
a bien été écrit _physiquement_ sur disque (c'est à dire que le disque a
lui même propagé l'écriture sur les plateaux, et pas uniquement dans sa
mémoire write-back)
Sinon, en plus général et moins standard, il y a atexit() et ses variantes (mais il y a des chances que cela soit court-circuité en cas d'exceptions, justement)
Et une bonne panne de courant sans onduleur est de toute manière fatale.
En général, on ne se pose pas ce genre de question: on est capable de prévoir des bases de données capables de récupérer le dernier état consistent, même après une panne brutale d'alimentation (par exemple, arrachage du câble d'alimentation).
Cela veut dire des fonctions comme fdatasync/fsync (POSIX ; <http://www.opengroup.org/onlinepubs/007908799/xsh/fdatasync.html> et <http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html>) qui permettent d'être _sûr_ que, après le retour de la fonction, le fichier a bien été écrit _physiquement_ sur disque (c'est à dire que le disque a lui même propagé l'écriture sur les plateaux, et pas uniquement dans sa mémoire write-back)
Xavier Roche
Pour la panne de courant, tu mets un onduleur un peu intelligent et tu es ramené au pb "extinction propre de la machine"
Reste la panne... d'onduleur, qui est toujours possible (même sur datacenter (..))
Pour la panne de courant, tu mets un onduleur un peu intelligent et tu
es ramené au pb "extinction propre de la machine"
Reste la panne... d'onduleur, qui est toujours possible (même sur
datacenter (..))
Pour la panne de courant, tu mets un onduleur un peu intelligent et tu es ramené au pb "extinction propre de la machine"
Reste la panne... d'onduleur, qui est toujours possible (même sur datacenter (..))
Et la météorite :-D
ALain Montfranc
Xavier Roche a écrit
Sinon, en plus général et moins standard, il y a atexit() et ses variantes (mais il y a des chances que cela soit court-circuité en cas d'exceptions, justement)
Et une bonne panne de courant sans onduleur est de toute manière fatale.
En général, on ne se pose pas ce genre de question: on est capable de prévoir des bases de données capables de récupérer le dernier état consistent, même après une panne brutale d'alimentation (par exemple, arrachage du câble d'alimentation).
Cela veut dire des fonctions comme fdatasync/fsync (POSIX ; <http://www.opengroup.org/onlinepubs/007908799/xsh/fdatasync.html> et <http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html>) qui permettent d'être _sûr_ que, après le retour de la fonction, le fichier a bien été écrit _physiquement_ sur disque (c'est à dire que le disque a lui même propagé l'écriture sur les plateaux, et pas uniquement dans sa mémoire write-back)
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process sur disque pour le reprendre plus tard (ce qui en faisant des dumps réguliers permettait de ne pas tout perdre) ?
Xavier Roche a écrit
Sinon, en plus général et moins standard, il y a atexit() et ses variantes
(mais il y a des chances que cela soit court-circuité en cas d'exceptions,
justement)
Et une bonne panne de courant sans onduleur est de toute manière fatale.
En général, on ne se pose pas ce genre de question: on est capable de prévoir
des bases de données capables de récupérer le dernier état consistent, même
après une panne brutale d'alimentation (par exemple, arrachage du câble
d'alimentation).
Cela veut dire des fonctions comme fdatasync/fsync (POSIX ;
<http://www.opengroup.org/onlinepubs/007908799/xsh/fdatasync.html> et
<http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html>) qui
permettent d'être _sûr_ que, après le retour de la fonction, le fichier a
bien été écrit _physiquement_ sur disque (c'est à dire que le disque a lui
même propagé l'écriture sur les plateaux, et pas uniquement dans sa mémoire
write-back)
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un
process sur disque pour le reprendre plus tard (ce qui en faisant des
dumps réguliers permettait de ne pas tout perdre) ?
Sinon, en plus général et moins standard, il y a atexit() et ses variantes (mais il y a des chances que cela soit court-circuité en cas d'exceptions, justement)
Et une bonne panne de courant sans onduleur est de toute manière fatale.
En général, on ne se pose pas ce genre de question: on est capable de prévoir des bases de données capables de récupérer le dernier état consistent, même après une panne brutale d'alimentation (par exemple, arrachage du câble d'alimentation).
Cela veut dire des fonctions comme fdatasync/fsync (POSIX ; <http://www.opengroup.org/onlinepubs/007908799/xsh/fdatasync.html> et <http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html>) qui permettent d'être _sûr_ que, après le retour de la fonction, le fichier a bien été écrit _physiquement_ sur disque (c'est à dire que le disque a lui même propagé l'écriture sur les plateaux, et pas uniquement dans sa mémoire write-back)
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process sur disque pour le reprendre plus tard (ce qui en faisant des dumps réguliers permettait de ne pas tout perdre) ?
Xavier Roche
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process sur disque pour le reprendre plus tard (ce qui en faisant des dumps réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il faudrait dumper tous les blocs mappés, et les remonter aux mêmes adresses, plus les handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais pour l'ensemble de l'OS l'opération est un peu plus simple.
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un
process sur disque pour le reprendre plus tard (ce qui en faisant des
dumps réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il
faudrait dumper tous les blocs mappés, et les remonter aux mêmes
adresses, plus les handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais
pour l'ensemble de l'OS l'opération est un peu plus simple.
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process sur disque pour le reprendre plus tard (ce qui en faisant des dumps réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il faudrait dumper tous les blocs mappés, et les remonter aux mêmes adresses, plus les handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais pour l'ensemble de l'OS l'opération est un peu plus simple.
ALain Montfranc
Xavier Roche a écrit
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process sur disque pour le reprendre plus tard (ce qui en faisant des dumps réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il faudrait dumper tous les blocs mappés, et les remonter aux mêmes adresses, plus les handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais pour l'ensemble de l'OS l'opération est un peu plus simple.
En 1989 TeX le faisait en s'auto-coredumpant lors de l'install pour accélerer les lancements en évitant du calcul
Xavier Roche a écrit
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process
sur disque pour le reprendre plus tard (ce qui en faisant des dumps
réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il faudrait
dumper tous les blocs mappés, et les remonter aux mêmes adresses, plus les
handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais pour
l'ensemble de l'OS l'opération est un peu plus simple.
En 1989 TeX le faisait en s'auto-coredumpant lors de l'install pour
accélerer les lancements en évitant du calcul
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process sur disque pour le reprendre plus tard (ce qui en faisant des dumps réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il faudrait dumper tous les blocs mappés, et les remonter aux mêmes adresses, plus les handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais pour l'ensemble de l'OS l'opération est un peu plus simple.
En 1989 TeX le faisait en s'auto-coredumpant lors de l'install pour accélerer les lancements en évitant du calcul
Jean-Marc Bourguet
ALain Montfranc writes:
Xavier Roche a écrit
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process sur disque pour le reprendre plus tard (ce qui en faisant des dumps réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il faudrait dumper tous les blocs mappés, et les remonter aux mêmes adresses, plus les handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais pour l'ensemble de l'OS l'opération est un peu plus simple.
En 1989 TeX le faisait en s'auto-coredumpant lors de l'install pour accélerer les lancements en évitant du calcul
emacs le fait aussi. Mais ils le font dans un état bien particulier, ce n'est pas des snapshorts d'un programme en court d'exécution qui ignore que ça se passe. C'est donc beaucoup plus simple.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
ALain Montfranc <x@x.con> writes:
Xavier Roche a écrit
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un
process sur disque pour le reprendre plus tard (ce qui en faisant des
dumps réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il
faudrait dumper tous les blocs mappés, et les remonter aux mêmes
adresses, plus les handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais
pour l'ensemble de l'OS l'opération est un peu plus simple.
En 1989 TeX le faisait en s'auto-coredumpant lors de l'install pour
accélerer les lancements en évitant du calcul
emacs le fait aussi. Mais ils le font dans un état bien particulier, ce
n'est pas des snapshorts d'un programme en court d'exécution qui ignore que
ça se passe. C'est donc beaucoup plus simple.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Ceci dit y'avais pas une lib qui permettait de dumper l'état d'un process sur disque pour le reprendre plus tard (ce qui en faisant des dumps réguliers permettait de ne pas tout perdre) ?
Cette solution me semblerait un peu complexe à mettre en oeuvre (il faudrait dumper tous les blocs mappés, et les remonter aux mêmes adresses, plus les handles ouverts...)
C'est en en gros ce que fait le mode "hibernation" des OS récents ; mais pour l'ensemble de l'OS l'opération est un peu plus simple.
En 1989 TeX le faisait en s'auto-coredumpant lors de l'install pour accélerer les lancements en évitant du calcul
emacs le fait aussi. Mais ils le font dans un état bien particulier, ce n'est pas des snapshorts d'un programme en court d'exécution qui ignore que ça se passe. C'est donc beaucoup plus simple.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
