exception

Le
Jean Pierre Daviau
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
--
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean Pierre Daviau
Le #984954
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
Le #984953
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

ALain Montfranc
Le #984952
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"

Xavier Roche
Le #984951
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 ;
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
Le #984950
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 (..))

ALain Montfranc
Le #984949
Xavier Roche a écrit
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
Le #984948
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 ;
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
Le #984779
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
Le #984778
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


Jean-Marc Bourguet
Le #984777
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


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



Publicité
Poster une réponse
Anonyme