j'ai une applie console pour laquelle je voudrais recuperer le control-C.
Facile me direz-vous ! Il faut utiliser SetConsoleCtrlHandler...
Le probleme c'est que si je fait throw d'une classe d'exception que
j'ai ecrite, ce throw ne s'effectue pas dans la pile de mon programme
mais dans une pile d'appel de Kernel32 et n'est donc pas catchée...
Une idée ???
Merci. Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://www-prima.inrialpes.fr/Vaufreydaz/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Frederic Lachasse
"Dominique Vaufreydaz" wrote in message news:bq53j9$ots$
Bonjour,
j'ai une applie console pour laquelle je voudrais recuperer le
control-C.
Facile me direz-vous ! Il faut utiliser SetConsoleCtrlHandler... Le probleme c'est que si je fait throw d'une classe d'exception que j'ai ecrite, ce throw ne s'effectue pas dans la pile de mon programme mais dans une pile d'appel de Kernel32 et n'est donc pas catchée...
Une idée ???
C'est parce que le handler est appelé dans un autre thread, créé temporairement par la console. Or un throw ne peut être attrappé que dans le même thread où il a été lancé. Le problème est donc d'interrompre le traitement de ton thread principal depuis un autre thread. Pour cela, 2 méthodes:
1) TerminateThread() permet d'arrêter un autre thread. En apparence très facile, mais malheureusement très dangeureux: il est problématique d'arrêter le thread principal, donc le traitement interruptible doit être fait dans un thread séparé, et il faut être sûr que l'arrêt brutal du thread, qui peut arriver à tout moment (surtout le plus mauvais moment), laisse le système dans un état stable. Cette méthode est souvent à déconseiller.
2) Le traitement (interruptible) teste régulièrement une variable (déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut choisir les meilleurs endroits pour tester cette variable: suffisament souvent pour s'arrêter rapidement et pas trop souvent pour ne pas ralentir le traitement. Contraignant, mais seule méthode pour être sûr d'un arrêt propre. Le control handler va juste changer cette variable pour signaler le Ctrl-C. L'arrêt lui même peut être de faire un throw d'un exception.
-- Frédéric Lachasse -
"Dominique Vaufreydaz" <Dominique-Doms.Vaufreydaz@imag.fr> wrote in message
news:bq53j9$ots$1@trompette.imag.fr...
Bonjour,
j'ai une applie console pour laquelle je voudrais recuperer le
control-C.
Facile me direz-vous ! Il faut utiliser SetConsoleCtrlHandler...
Le probleme c'est que si je fait throw d'une classe d'exception que
j'ai ecrite, ce throw ne s'effectue pas dans la pile de mon programme
mais dans une pile d'appel de Kernel32 et n'est donc pas catchée...
Une idée ???
C'est parce que le handler est appelé dans un autre thread, créé
temporairement par la console. Or un throw ne peut être attrappé que dans le
même thread où il a été lancé. Le problème est donc d'interrompre le
traitement de ton thread principal depuis un autre thread. Pour cela, 2
méthodes:
1) TerminateThread() permet d'arrêter un autre thread. En apparence très
facile, mais malheureusement très dangeureux: il est problématique d'arrêter
le thread principal, donc le traitement interruptible doit être fait dans un
thread séparé, et il faut être sûr que l'arrêt brutal du thread, qui peut
arriver à tout moment (surtout le plus mauvais moment), laisse le système
dans un état stable. Cette méthode est souvent à déconseiller.
2) Le traitement (interruptible) teste régulièrement une variable
(déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut
choisir les meilleurs endroits pour tester cette variable: suffisament
souvent pour s'arrêter rapidement et pas trop souvent pour ne pas ralentir
le traitement. Contraignant, mais seule méthode pour être sûr d'un arrêt
propre. Le control handler va juste changer cette variable pour signaler le
Ctrl-C. L'arrêt lui même peut être de faire un throw d'un exception.
"Dominique Vaufreydaz" wrote in message news:bq53j9$ots$
Bonjour,
j'ai une applie console pour laquelle je voudrais recuperer le
control-C.
Facile me direz-vous ! Il faut utiliser SetConsoleCtrlHandler... Le probleme c'est que si je fait throw d'une classe d'exception que j'ai ecrite, ce throw ne s'effectue pas dans la pile de mon programme mais dans une pile d'appel de Kernel32 et n'est donc pas catchée...
Une idée ???
C'est parce que le handler est appelé dans un autre thread, créé temporairement par la console. Or un throw ne peut être attrappé que dans le même thread où il a été lancé. Le problème est donc d'interrompre le traitement de ton thread principal depuis un autre thread. Pour cela, 2 méthodes:
1) TerminateThread() permet d'arrêter un autre thread. En apparence très facile, mais malheureusement très dangeureux: il est problématique d'arrêter le thread principal, donc le traitement interruptible doit être fait dans un thread séparé, et il faut être sûr que l'arrêt brutal du thread, qui peut arriver à tout moment (surtout le plus mauvais moment), laisse le système dans un état stable. Cette méthode est souvent à déconseiller.
2) Le traitement (interruptible) teste régulièrement une variable (déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut choisir les meilleurs endroits pour tester cette variable: suffisament souvent pour s'arrêter rapidement et pas trop souvent pour ne pas ralentir le traitement. Contraignant, mais seule méthode pour être sûr d'un arrêt propre. Le control handler va juste changer cette variable pour signaler le Ctrl-C. L'arrêt lui même peut être de faire un throw d'un exception.
-- Frédéric Lachasse -
Dominique Vaufreydaz
Bonjour,
C'est parce que le handler est appelé dans un autre thread, créé temporairement par la console. Or un throw ne peut être attrappé que dans le même thread où il a été lancé.
On est bien d'accord, c'est ce que je voulais sire en disant que ca s'executait dans la pile d'appel de kernel32... D'un tread d'un fonction de kernel 32...
1) TerminateThread() permet d'arrêter un autre thread. En apparence très
Je veux pas...
2) Le traitement (interruptible) teste régulièrement une variable (déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut
Difficile, parceque je n'ai pas toujours la main (d'ou l'interet d'avoir un control-C dans la "bonne pile"...).
Bon, alors pourquoi il n'envoit pas d'exception sauf quand on est avec un debugguer ??? C'est une tres mauvaise idee ! N'y-a-t-il pas un moyen de lui fait envoyer cette exception ???
Merci. Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://www-prima.inrialpes.fr/Vaufreydaz/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
C'est parce que le handler est appelé dans un autre thread, créé
temporairement par la console. Or un throw ne peut être attrappé que dans le
même thread où il a été lancé.
On est bien d'accord, c'est ce que je voulais sire en disant que ca
s'executait dans la pile d'appel de kernel32... D'un tread d'un fonction
de kernel 32...
1) TerminateThread() permet d'arrêter un autre thread. En apparence très
Je veux pas...
2) Le traitement (interruptible) teste régulièrement une variable
(déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut
Difficile, parceque je n'ai pas toujours la main (d'ou l'interet d'avoir un
control-C dans la "bonne pile"...).
Bon, alors pourquoi il n'envoit pas d'exception sauf quand on est avec un
debugguer ??? C'est une tres mauvaise idee ! N'y-a-t-il pas un moyen de
lui fait envoyer cette exception ???
Merci. Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://www-prima.inrialpes.fr/Vaufreydaz/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
C'est parce que le handler est appelé dans un autre thread, créé temporairement par la console. Or un throw ne peut être attrappé que dans le même thread où il a été lancé.
On est bien d'accord, c'est ce que je voulais sire en disant que ca s'executait dans la pile d'appel de kernel32... D'un tread d'un fonction de kernel 32...
1) TerminateThread() permet d'arrêter un autre thread. En apparence très
Je veux pas...
2) Le traitement (interruptible) teste régulièrement une variable (déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut
Difficile, parceque je n'ai pas toujours la main (d'ou l'interet d'avoir un control-C dans la "bonne pile"...).
Bon, alors pourquoi il n'envoit pas d'exception sauf quand on est avec un debugguer ??? C'est une tres mauvaise idee ! N'y-a-t-il pas un moyen de lui fait envoyer cette exception ???
Merci. Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://www-prima.inrialpes.fr/Vaufreydaz/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Frederic Lachasse
"Dominique Vaufreydaz" wrote in message news:bq789d$5db$
Bonjour,
> C'est parce que le handler est appelé dans un autre thread, créé > temporairement par la console. Or un throw ne peut être attrappé que
dans le
> même thread où il a été lancé.
On est bien d'accord, c'est ce que je voulais sire en disant que ca s'executait dans la pile d'appel de kernel32... D'un tread d'un
fonction
de kernel 32...
> 1) TerminateThread() permet d'arrêter un autre thread. En apparence
très
Je veux pas...
Et tu as raison...
> 2) Le traitement (interruptible) teste régulièrement une variable > (déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut
Difficile, parceque je n'ai pas toujours la main (d'ou l'interet
d'avoir un
control-C dans la "bonne pile"...).
Pourquoi? Parce que tu fais des E/S bloquant, peut-être? Il est souvent possible de faire ces opérations d'une manière asynchrone, et même assez souvent de les interrompres.
Bon, alors pourquoi il n'envoit pas d'exception sauf quand on est avec
un
debugguer ???
L'exception est envoyée. C'est juste que personne ne l'attrappe.
C'est une tres mauvaise idee ! N'y-a-t-il pas un moyen de lui fait envoyer cette exception ???
Non. Il est très délicat d'interrompre brutalement un traitement et de correctement désallouer les resources utilisées. Pour imaginer les dégats, lire les chapitres "Threads et Sections critiques" (ou comment des structures de données peuvent se retrouver dans un état bizarre si on interrompt un traitement au moment le plus inoportun) et "Exception safety" (ou comment récupérer les resources allouées). C'est la raison pour laquelle TerminateThread() est à éviter. Et la raison pour laquelle Windows évite d'interrompre les programmes sans en avertir le programmeur.
-- Frédéric Lachasse -
"Dominique Vaufreydaz" <Dominique-Doms.Vaufreydaz@imag.fr> wrote in message
news:bq789d$5db$1@trompette.imag.fr...
Bonjour,
> C'est parce que le handler est appelé dans un autre thread, créé
> temporairement par la console. Or un throw ne peut être attrappé que
dans le
> même thread où il a été lancé.
On est bien d'accord, c'est ce que je voulais sire en disant que ca
s'executait dans la pile d'appel de kernel32... D'un tread d'un
fonction
de kernel 32...
> 1) TerminateThread() permet d'arrêter un autre thread. En apparence
très
Je veux pas...
Et tu as raison...
> 2) Le traitement (interruptible) teste régulièrement une variable
> (déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut
Difficile, parceque je n'ai pas toujours la main (d'ou l'interet
d'avoir un
control-C dans la "bonne pile"...).
Pourquoi? Parce que tu fais des E/S bloquant, peut-être? Il est souvent
possible de faire ces opérations d'une manière asynchrone, et même assez
souvent de les interrompres.
Bon, alors pourquoi il n'envoit pas d'exception sauf quand on est avec
un
debugguer ???
L'exception est envoyée. C'est juste que personne ne l'attrappe.
C'est une tres mauvaise idee ! N'y-a-t-il pas un moyen de
lui fait envoyer cette exception ???
Non. Il est très délicat d'interrompre brutalement un traitement et de
correctement désallouer les resources utilisées. Pour imaginer les dégats,
lire les chapitres "Threads et Sections critiques" (ou comment des
structures de données peuvent se retrouver dans un état bizarre si on
interrompt un traitement au moment le plus inoportun) et "Exception safety"
(ou comment récupérer les resources allouées). C'est la raison pour laquelle
TerminateThread() est à éviter. Et la raison pour laquelle Windows évite
d'interrompre les programmes sans en avertir le programmeur.
"Dominique Vaufreydaz" wrote in message news:bq789d$5db$
Bonjour,
> C'est parce que le handler est appelé dans un autre thread, créé > temporairement par la console. Or un throw ne peut être attrappé que
dans le
> même thread où il a été lancé.
On est bien d'accord, c'est ce que je voulais sire en disant que ca s'executait dans la pile d'appel de kernel32... D'un tread d'un
fonction
de kernel 32...
> 1) TerminateThread() permet d'arrêter un autre thread. En apparence
très
Je veux pas...
Et tu as raison...
> 2) Le traitement (interruptible) teste régulièrement une variable > (déclaré "volatile") d'état qui sert de signal pour s'arrêter. Il faut
Difficile, parceque je n'ai pas toujours la main (d'ou l'interet
d'avoir un
control-C dans la "bonne pile"...).
Pourquoi? Parce que tu fais des E/S bloquant, peut-être? Il est souvent possible de faire ces opérations d'une manière asynchrone, et même assez souvent de les interrompres.
Bon, alors pourquoi il n'envoit pas d'exception sauf quand on est avec
un
debugguer ???
L'exception est envoyée. C'est juste que personne ne l'attrappe.
C'est une tres mauvaise idee ! N'y-a-t-il pas un moyen de lui fait envoyer cette exception ???
Non. Il est très délicat d'interrompre brutalement un traitement et de correctement désallouer les resources utilisées. Pour imaginer les dégats, lire les chapitres "Threads et Sections critiques" (ou comment des structures de données peuvent se retrouver dans un état bizarre si on interrompt un traitement au moment le plus inoportun) et "Exception safety" (ou comment récupérer les resources allouées). C'est la raison pour laquelle TerminateThread() est à éviter. Et la raison pour laquelle Windows évite d'interrompre les programmes sans en avertir le programmeur.
-- Frédéric Lachasse -
Dominique Vaufreydaz
Bonjour,
Pourquoi? Parce que tu fais des E/S bloquant, peut-être? Il est souvent possible de faire ces opérations d'une manière asynchrone, et même assez souvent de les interrompres.
Non, parceque j'appelle des routines en C que je n'ai pas ecrite, je ne me situe qu'au niveau d'une machine virtuelle qui gere le scripting de la chose...
L'exception est envoyée. C'est juste que personne ne l'attrappe.
Ben moi, je veux bien l'attraper, mais meme en mettant catch(...), je ne catch rien sur control-C (sur tout autre evenement, debodement de pile, memoire not read, etc., je recois bien...).
Non. Il est très délicat d'interrompre brutalement un traitement et de correctement désallouer les resources utilisées. Pour imaginer les dégats, lire les chapitres "Threads et Sections critiques" (ou comment des structures de données peuvent se retrouver dans un état bizarre si on interrompt un traitement au moment le plus inoportun) et "Exception safety" (ou comment récupérer les resources allouées). C'est la raison pour laquelle TerminateThread() est à éviter. Et la raison pour laquelle Windows évite d'interrompre les programmes sans en avertir le programmeur.
Donc aucune solution a mon probleme... Bon alors je laisse le controle-C a la discretion du systeme => Windows !
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://www-prima.inrialpes.fr/Vaufreydaz/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
Pourquoi? Parce que tu fais des E/S bloquant, peut-être? Il est souvent
possible de faire ces opérations d'une manière asynchrone, et même assez
souvent de les interrompres.
Non, parceque j'appelle des routines en C que je n'ai pas ecrite,
je ne me situe qu'au niveau d'une machine virtuelle qui gere le scripting
de la chose...
L'exception est envoyée. C'est juste que personne ne l'attrappe.
Ben moi, je veux bien l'attraper, mais meme en mettant
catch(...), je ne catch rien sur control-C (sur tout autre
evenement, debodement de pile, memoire not read, etc.,
je recois bien...).
Non. Il est très délicat d'interrompre brutalement un traitement et de
correctement désallouer les resources utilisées. Pour imaginer les dégats,
lire les chapitres "Threads et Sections critiques" (ou comment des
structures de données peuvent se retrouver dans un état bizarre si on
interrompt un traitement au moment le plus inoportun) et "Exception safety"
(ou comment récupérer les resources allouées). C'est la raison pour laquelle
TerminateThread() est à éviter. Et la raison pour laquelle Windows évite
d'interrompre les programmes sans en avertir le programmeur.
Donc aucune solution a mon probleme... Bon alors je laisse le controle-C
a la discretion du systeme => Windows !
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://www-prima.inrialpes.fr/Vaufreydaz/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Pourquoi? Parce que tu fais des E/S bloquant, peut-être? Il est souvent possible de faire ces opérations d'une manière asynchrone, et même assez souvent de les interrompres.
Non, parceque j'appelle des routines en C que je n'ai pas ecrite, je ne me situe qu'au niveau d'une machine virtuelle qui gere le scripting de la chose...
L'exception est envoyée. C'est juste que personne ne l'attrappe.
Ben moi, je veux bien l'attraper, mais meme en mettant catch(...), je ne catch rien sur control-C (sur tout autre evenement, debodement de pile, memoire not read, etc., je recois bien...).
Non. Il est très délicat d'interrompre brutalement un traitement et de correctement désallouer les resources utilisées. Pour imaginer les dégats, lire les chapitres "Threads et Sections critiques" (ou comment des structures de données peuvent se retrouver dans un état bizarre si on interrompt un traitement au moment le plus inoportun) et "Exception safety" (ou comment récupérer les resources allouées). C'est la raison pour laquelle TerminateThread() est à éviter. Et la raison pour laquelle Windows évite d'interrompre les programmes sans en avertir le programmeur.
Donc aucune solution a mon probleme... Bon alors je laisse le controle-C a la discretion du systeme => Windows !
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://www-prima.inrialpes.fr/Vaufreydaz/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Arnaud Debaene
Dominique Vaufreydaz wrote:
Donc aucune solution a mon probleme... Bon alors je laisse le controle-C a la discretion du systeme => Windows !
Mais si c'est gérable : dans le handler de CTRL+C tu lèves un flag, et dans le thread principal de ta machine virtuelle, tu testes régulièrement l'état de ce flag (par exemple après l'appel à chacune des routines C applicatives) et tu lèves ton exception si ce flag est positionné. C'est sûr que si les routines en questions ne sont pas concues pour être interruptibles et qu'elles sont longues, ca devient plus compliqué et tu dois éventuellement lancer ces routines dans un thread séparé que tu termines de force (TerminateThread) si ca n'a pas d'influence trop néfaste sur tes données.
Arnaud
Dominique Vaufreydaz wrote:
Donc aucune solution a mon probleme... Bon alors je laisse le
controle-C a la discretion du systeme => Windows !
Mais si c'est gérable : dans le handler de CTRL+C tu lèves un flag, et dans
le thread principal de ta machine virtuelle, tu testes régulièrement l'état
de ce flag (par exemple après l'appel à chacune des routines C applicatives)
et tu lèves ton exception si ce flag est positionné. C'est sûr que si les
routines en questions ne sont pas concues pour être interruptibles et
qu'elles sont longues, ca devient plus compliqué et tu dois éventuellement
lancer ces routines dans un thread séparé que tu termines de force
(TerminateThread) si ca n'a pas d'influence trop néfaste sur tes données.
Donc aucune solution a mon probleme... Bon alors je laisse le controle-C a la discretion du systeme => Windows !
Mais si c'est gérable : dans le handler de CTRL+C tu lèves un flag, et dans le thread principal de ta machine virtuelle, tu testes régulièrement l'état de ce flag (par exemple après l'appel à chacune des routines C applicatives) et tu lèves ton exception si ce flag est positionné. C'est sûr que si les routines en questions ne sont pas concues pour être interruptibles et qu'elles sont longues, ca devient plus compliqué et tu dois éventuellement lancer ces routines dans un thread séparé que tu termines de force (TerminateThread) si ca n'a pas d'influence trop néfaste sur tes données.
Arnaud
Dominique Vaufreydaz
Bonjour,
Mais si c'est gérable : dans le handler de CTRL+C tu lèves un flag, et dans le thread principal de ta machine virtuelle, tu testes régulièrement l'état de ce flag (par exemple après l'appel à chacune des routines C applicatives) et tu lèves ton exception si ce flag est positionné. C'est sûr que si les routines en questions ne sont pas concues pour être interruptibles et qu'elles sont longues, ca devient plus compliqué et tu dois éventuellement lancer ces routines dans un thread séparé que tu termines de force (TerminateThread) si ca n'a pas d'influence trop néfaste sur tes données.
C'est ca le hic, c'est que je n'ai pas d'autre choix que celui que tu indiques auquel je me suis resolu. Une bonne combinaison de WaitForSingleObject et de tests de flag fonctionne a merveille avec 1 thread. Mais bon, dommage de ne pas voir passer l'exception... Notons au passage que la MV n'avait pas ete pensee pour etre multithread... Ca m'impose quelques modifications (les fonctions C pouvant appeler des fonctions touchant directement l'etat de la MV).
Je comprends bien le design : une erreur memoire n'est devolue qu'a un seul thread => on peut lui jeter une exception. Le Controle-C s'applique a tout le monde (on l'enverrait donc a tout le monde, bof). Notons que l'idee serait de laisser ce choix a la discretion du programmeur...
Bon, c'est pas grave, j'ai fait comme ca et puis c'est tout... Notons que le probleme est le meme sous Linux. Un "bus error" appelle un signal qui peut faire un throw dans la bonne pile, pas le signal handler du control-c...
Vala. Merci a tous. Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://www-prima.inrialpes.fr/Vaufreydaz/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
Mais si c'est gérable : dans le handler de CTRL+C tu lèves un flag, et dans
le thread principal de ta machine virtuelle, tu testes régulièrement l'état
de ce flag (par exemple après l'appel à chacune des routines C applicatives)
et tu lèves ton exception si ce flag est positionné. C'est sûr que si les
routines en questions ne sont pas concues pour être interruptibles et
qu'elles sont longues, ca devient plus compliqué et tu dois éventuellement
lancer ces routines dans un thread séparé que tu termines de force
(TerminateThread) si ca n'a pas d'influence trop néfaste sur tes données.
C'est ca le hic, c'est que je n'ai pas d'autre choix que celui que tu indiques
auquel je me suis resolu. Une bonne combinaison de WaitForSingleObject
et de tests de flag fonctionne a merveille avec 1 thread. Mais bon, dommage
de ne pas voir passer l'exception... Notons au passage que la MV n'avait
pas ete pensee pour etre multithread... Ca m'impose quelques modifications
(les fonctions C pouvant appeler des fonctions touchant directement l'etat de
la MV).
Je comprends bien le design : une erreur memoire n'est devolue qu'a un seul
thread => on peut lui jeter une exception. Le Controle-C s'applique
a tout le monde (on l'enverrait donc a tout le monde, bof). Notons que l'idee
serait de laisser ce choix a la discretion du programmeur...
Bon, c'est pas grave, j'ai fait comme ca et puis c'est tout... Notons que le probleme
est le meme sous Linux. Un "bus error" appelle un signal qui peut faire un throw
dans la bonne pile, pas le signal handler du control-c...
Vala. Merci a tous. Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://www-prima.inrialpes.fr/Vaufreydaz/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Mais si c'est gérable : dans le handler de CTRL+C tu lèves un flag, et dans le thread principal de ta machine virtuelle, tu testes régulièrement l'état de ce flag (par exemple après l'appel à chacune des routines C applicatives) et tu lèves ton exception si ce flag est positionné. C'est sûr que si les routines en questions ne sont pas concues pour être interruptibles et qu'elles sont longues, ca devient plus compliqué et tu dois éventuellement lancer ces routines dans un thread séparé que tu termines de force (TerminateThread) si ca n'a pas d'influence trop néfaste sur tes données.
C'est ca le hic, c'est que je n'ai pas d'autre choix que celui que tu indiques auquel je me suis resolu. Une bonne combinaison de WaitForSingleObject et de tests de flag fonctionne a merveille avec 1 thread. Mais bon, dommage de ne pas voir passer l'exception... Notons au passage que la MV n'avait pas ete pensee pour etre multithread... Ca m'impose quelques modifications (les fonctions C pouvant appeler des fonctions touchant directement l'etat de la MV).
Je comprends bien le design : une erreur memoire n'est devolue qu'a un seul thread => on peut lui jeter une exception. Le Controle-C s'applique a tout le monde (on l'enverrait donc a tout le monde, bof). Notons que l'idee serait de laisser ce choix a la discretion du programmeur...
Bon, c'est pas grave, j'ai fait comme ca et puis c'est tout... Notons que le probleme est le meme sous Linux. Un "bus error" appelle un signal qui peut faire un throw dans la bonne pile, pas le signal handler du control-c...
Vala. Merci a tous. Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://www-prima.inrialpes.fr/Vaufreydaz/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
