C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Scope bei Signalen          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Georg Maaß Guest Posted: Sun Dec 28, 2003 7:27 pm    Post subject: Scope bei Signalen Wenn mein Programm von einem Signal getroffen wird, in was für einem Scope läuft dann der Signal-Handler? Insbesondere, wo muß ich ein try/catch hinschreiben, um eventuelle Exceptions, die so ein Signal-Handler werfen könnte, zu behandeln? Gehört das try/catch ins main, oder gehört es in den Programmzweig rein, in dem das Signal auftrat, oder kann man Exceptions von Signal-Handlern gar nicht fangen? Wenn ich z.B. über eine Pipe ein anderes Programm anquatsche, dann kann ein SIG_PIPE auftreten, das mir signalisiert, daß die Pipe abgestorben ist. Bisher habe ich dann einfach das Programm beendet. In einem Server jedoch kann ich ja wegen so einer Lapalie nicht den ganzen Server beenden, sondern da wäre mir eine Exception lieber, welche den Programmteil, der die Pipe nutzt, veranlasßt, mit einer Fehlermeldung abzubrechen, so daß der Server sich neuen Aufgaben widmen kann. Wenn ich aber im Signal-Handler eventuell keine fangbare Exception werfen kann, dann muß ich die Information, daß die Pipe kaputt ist, anders an die Routine übertragen, welche auf eine Antwort der Pipe wartet. Beide Routine, sowohl die, welche mit der Pipe arbeitet, als auch der Signal-Handler sind Methoden einer Klasse. Kennt der Signal-Handler während der Signal-Behandlung die Klassen-Instanz zu der er gehört, so daß ich im Signal-Handler alternativ zur Exception eventuell eine Membervariable mit einem Flag von "ganz" auf "kaputt" umschalten könnte? -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Georg Maaß Guest Posted: Sun Dec 28, 2003 8:24 pm    Post subject: Re: Scope bei Signalen Georg Maaß wrote: Quote: Kennt der Signal-Handler während der Signal-Behandlung die Klassen-Instanz zu der er gehört, so daß ich im Signal-Handler alternativ zur Exception eventuell eine Membervariable mit einem Flag von "ganz" auf "kaputt" umschalten könnte? Diese Idee kann ich schon mal begraben, denn den Signal-Handler akzeptiert er nur dann, wenn er ein static Member ist. Somit kennt er also seine Instanz nicht. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Thomas Maeder Guest Posted: Sun Dec 28, 2003 9:39 pm    Post subject: Re: Scope bei Signalen Georg Maaß <georg (AT) bioshop (DOT) de> writes: Quote: Wenn mein Programm von einem Signal getroffen wird, in was für einem Scope läuft dann der Signal-Handler? Insbesondere, wo muß ich ein try/catch hinschreiben, um eventuelle Exceptions, die so ein Signal-Handler werfen könnte, zu behandeln? Gar nicht. Ein signal-Handler läuft z.B. während eines Interrupt-Handlers. Das einzige, was ich in einem signal-Handler mache, ist ein entsprechend ausgestattetes Flag setzen, z.B.: namespace { sig_atomic_t volatile signalled(0); } void signal_handler(int signum) { signalled = 1; } Die Ereignisschlaufe der Anwendung prüft dann signalled. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Marco Budde Guest Posted: Mon Dec 29, 2003 10:25 am    Post subject: Re: Scope bei Signalen Georg Maaß wrote: Quote: Wenn mein Programm von einem Signal getroffen wird, in was für einem Scope läuft dann der Signal-Handler? Insbesondere, wo muß ich ein try/catch hinschreiben, um eventuelle Exceptions, die so ein Signal-Handler werfen könnte, zu behandeln? Ich würde einfach mal behaupten, daß die Callback Funktion überhaupt keine Exceptions werfen darf. Schließlich ist das eine C- und keine C++-Funktion. Von daher sollte die Funktion einen "globalen" Catch All (mit Entsorgung der Exceptions) Block enthalten. Quote: Gehört das try/catch ins main, oder gehört es in den Programmzweig rein, in dem das Signal auftrat, oder kann man Exceptions von Signal-Handlern gar nicht fangen? Im Handler selbst natürlich schon, wobei ein solcher Handler in der Regel nur eine boolsche Variable setzt, die anzeigt, daß ein Signal aufgetreten ist. Diese wird dann im normalen Context "gepollt" (vergleiche Mutex). Quote: Wenn ich z.B. über eine Pipe ein anderes Programm anquatsche, dann kann ein SIG_PIPE auftreten, das mir signalisiert, daß die Pipe abgestorben ist. Bisher habe ich dann einfach das Programm beendet. In einem Server jedoch kann ich ja wegen so einer Lapalie nicht den ganzen Server beenden, sondern da wäre mir eine Exception lieber, welche den Programmteil, der die Pipe nutzt, veranlasßt, mit einer Fehlermeldung abzubrechen, so daß der Server sich neuen Aufgaben widmen kann. IHMO war das von den Designer eine ziemlich blöde Idee, einen solchen Fehler per Signal zu melden (habe ich mich auch schon drüber gewundert). Wenn Du eine Pipe Klasse hast, spendiere dieser doch einfach eine statische Member Variable, die einen Error anzeigt. Der Signal Handler setzt einfach diese Variable. Die "Main" Loop der Pipe Klasse selbst prüft regelmäßig diese Variable und wirft im Fehlerfall dann eine Exception. Quote: wartet. Beide Routine, sowohl die, welche mit der Pipe arbeitet, als auch der Signal-Handler sind Methoden einer Klasse. Das letztere dürfte aber eine statische Methode sein, richtig? Quote: Kennt der Signal-Handler während der Signal-Behandlung die Klassen-Instanz zu der er gehört, Mit dem Handler hat das nichts zu tun. Ein Funktionszeiger kann nur auf Funktionen oder auf *statische* Methoden einer Klasse zeigen. Statische Methoden gehören eben gerade nicht zu einer Instanz. Üblicherweise haben Callback Funktionen deshalb einen Parameter vom Typ "void *", dem private Daten übergeben werden, die man bei der Registrierung der Callback Funktion angegeben hat. Hier kann man dann wunderbar einen Zeiger auf eine Instanz übergeben und in der Callback Funktion entsprechend casten. signal() kennt dieses Konzept leider nicht, so daß man an globalen Variablen nicht vorbeikommt . Quote: so daß ich im Signal-Handler alternativ zur Exception eventuell eine Membervariable mit einem Flag von "ganz" auf "kaputt" umschalten könnte? Membervariable geht hier leider nicht, muß global sein. cu, Marco -- S: Minolta: Winkelsucher (VN), VC-9 E-Mail: mb-news-b<ät>linuxhaven.de Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Georg Maaß Guest Posted: Mon Dec 29, 2003 10:33 am    Post subject: Re: Scope bei Signalen Thomas Maeder wrote: Quote: Ein signal-Handler läuft z.B. während eines Interrupt-Handlers. Das einzige, was ich in einem signal-Handler mache, ist ein entsprechend ausgestattetes Flag setzen, z.B.: namespace { sig_atomic_t volatile signalled(0); } void signal_handler(int signum) { signalled = 1; } Die Ereignisschlaufe der Anwendung prüft dann signalled. Hm, das ist dann aber eine globale Variable. Sowas verträgt sich aber nicht sonderlich gut mit Multithreading. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Marco Budde Guest Posted: Tue Dec 30, 2003 7:10 am    Post subject: Re: Scope bei Signalen Georg Maaß wrote: Quote: Hm, das ist dann aber eine globale Variable. Das ist auch genau der Grund, warum diese Rückmeldung via Signale ziemlich blöde ist. Quote: Sowas verträgt sich aber nicht sonderlich gut mit Multithreading. Warum? Du kannst sowieso nur einen zentralen Signal Handler registrieren. Es darf also im Prinzip nur eine zentrale "Pipe" Klasse geben, die zu einem Signal führen kann. cu, Marco -- S: Minolta: Winkelsucher (VN), VC-9 E-Mail: mb-news-b<ät>linuxhaven.de Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Thomas Maeder Guest Posted: Tue Dec 30, 2003 8:43 am    Post subject: Re: Scope bei Signalen Georg Maaß <spam (AT) clausmark (DOT) com> writes: Quote: namespace { sig_atomic_t volatile signalled(0); } void signal_handler(int signum) { signalled = 1; } Die Ereignisschlaufe der Anwendung prüft dann signalled. Hm, das ist dann aber eine globale Variable. Sowas verträgt sich aber nicht sonderlich gut mit Multithreading. Na ja. signalled ist garantiert "signal proof". Ich würde davon ausgehen, dass das auch bedeutet, dass sie "thread proof" ist bei jeder vernünftigen Threads-Implementierung. Aber sobald wir über Threads schreiben, sind wir off-topic hier. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Markus Breuer Guest Posted: Tue Dec 30, 2003 11:04 pm    Post subject: Re: Scope bei Signalen Georg Maaß schrieb: Quote: Wenn mein Programm von einem Signal getroffen wird, in was für einem Scope läuft dann der Signal-Handler? Insbesondere, wo muß ich ein try/catch hinschreiben, um eventuelle Exceptions, die so ein Signal-Handler werfen könnte, zu behandeln? Gehört das try/catch ins main, oder gehört es in den Programmzweig rein, in dem das Signal auftrat, oder kann man Exceptions von Signal-Handlern gar nicht fangen? Wenn ich z.B. über eine Pipe ein anderes Programm anquatsche, dann kann ein SIG_PIPE auftreten, das mir signalisiert, daß die Pipe abgestorben ist. Bisher habe ich dann einfach das Programm beendet. In einem Server jedoch kann ich ja wegen so einer Lapalie nicht den ganzen Server beenden, sondern da wäre mir eine Exception lieber, welche den Programmteil, der die Pipe nutzt, veranlasßt, mit einer Fehlermeldung abzubrechen, so daß der Server sich neuen Aufgaben widmen kann. Wenn ich aber im Signal-Handler eventuell keine fangbare Exception werfen kann, dann muß ich die Information, daß die Pipe kaputt ist, anders an die Routine übertragen, welche auf eine Antwort der Pipe wartet. Beide Routine, sowohl die, welche mit der Pipe arbeitet, als auch der Signal-Handler sind Methoden einer Klasse. Kennt der Signal-Handler während der Signal-Behandlung die Klassen-Instanz zu der er gehört, so daß ich im Signal-Handler alternativ zur Exception eventuell eine Membervariable mit einem Flag von "ganz" auf "kaputt" umschalten könnte? Den signal handler darfst du nicht als eine normale Funktion betrachten. Auch wenn es sich hier um eine von dir defnierte Funktion handelt, so wird sie von os Funktionen aufgerufen. Möglicherweise führt diese Funktion noch Code aus, wenn der handler retuniert!? Mit einer Exception würdest du den Ablauf da durcheinander bringen. Davon einmal abgesehen, ist der aufrufende Code möglicherweise gar nicht in C++ geschrieben und legt auf dem Stack demnach auch keine Informationen zum Exception Handling ab. Die Exception verhält sich an dieser Stelle undefiniert und im besten Fall erhälst du einen core dump. Ein weiterer Aspekt ist die Stelle, wo die Exception ausgeführt wird. Was soll passieren, wenn das Signal eine Funktion mit dem Zusatz throw() trifft? In einer multi-threaded Applikation darfst du dir dann noch die Frage stellen, in welchem Thread das Signal auftritt, denn auch das ist nicht spezifiziert. Mein Rat ist, ein globales Flag zu setzen und dieses im Hauptprogramm abzufragen. Polling ist zwar unschön, aber an dieser Stelle die beste Lösung. Semaphoren oder Mutexe kann man zwar grundsätzlich auch in den Handlern verwendet, allerdings gibt es hier eine Reihe von Dead-Lock Situationen mehr, viele OS halten für die Dauer des Handlers nämliche alle Threads an ... Grundsätzlich solltest du aber auch nur Signale abfragen, die du auch wirklich verarbeiten möchtest. Beim Installieren das Handlers kannst du dazu eine passende ignore-mask setzen. Markus -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Georg Maaß Guest Posted: Wed Dec 31, 2003 8:54 am    Post subject: Re: Scope bei Signalen Markus Breuer wrote: Quote: Den signal handler darfst du nicht als eine normale Funktion betrachten. Deshalb ja auch meine Frage, weil mir das eben schon von der Theorie her komisch vorkam. [...] Quote: Ein weiterer Aspekt ist die Stelle, wo die Exception ausgeführt wird. Was soll passieren, wenn das Signal eine Funktion mit dem Zusatz throw() trifft? Ein weiteres Problem, auf das ich noch gar nicht gekommen bin, das mir aber sicher demnächst aufgefallen wäre, weil ich schon bei einigen Methoden das throw wegnehmen mußte, da sonst die Signatur nicht paßte. Normalerweise gebe ich nämlich immer explizit an, was ich werfe. Wenn da tatsächlich noch andere Exceptions runfliegen als meine eigenen, dann ist das natürlich ein Bug in meinem Code, der dann in main aufgefangen werden muß, zu einer Fehlermeldung führen soll mit anschließendem Programmende, denn auf Bugs kann man nur mit Programmende sinnvoll reagieren, weil man ja schließlich nicht weiß, was alles kaputt ist. Quote: In einer multi-threaded Applikation darfst du dir dann noch die Frage stellen, in welchem Thread das Signal auftritt, denn auch das ist nicht spezifiziert. Da haben wohl Hunderte von Leuten an verschiedenen Stellen gebaut und nicht mit einander geredet, so daß die Teile nicht zusammen passen. Kein Wunder, daß der Turm von Babel nichts geworden ist. Quote: Grundsätzlich solltest du aber auch nur Signale abfragen, die du auch wirklich verarbeiten möchtest. Beim Installieren das Handlers kannst du dazu eine passende ignore-mask setzen. Ich will ja das Signal verarbeiten und zwar so, daß die Schleife abbricht. -- Georg Maaß - bioshop.de D-76227 Karlsruhe, Westmarkstraße 82 HTML, XML / JavaScript, C++, Java, PHP, VB / CGI, JSP, ASP, ASP.net - The ultimate DHTML engine: http://gml-modul.sourceforge.net - http://sourceforge.net/projects/gml-modul -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Hubert Schmid Guest Posted: Wed Dec 31, 2003 9:53 am    Post subject: Re: Scope bei Signalen Georg Maaß <georg (AT) bioshop (DOT) de> writes: Quote: Wenn ich z.B. über eine Pipe ein anderes Programm anquatsche, dann kann ein SIG_PIPE auftreten, das mir signalisiert, daß die Pipe abgestorben ist. Bisher habe ich dann einfach das Programm beendet. In einem Server jedoch kann ich ja wegen so einer Lapalie nicht den ganzen Server beenden, sondern da wäre mir eine Exception lieber, welche den Programmteil, der die Pipe nutzt, veranlasßt, mit einer Fehlermeldung abzubrechen, so daß der Server sich neuen Aufgaben widmen kann. Das ist etwas OT und plattformabhängig, aber damit kann das eigentliche Problem einfach gelöst werden: Wenn du das Signal SIGPIPE ignorierst (mit signal(SIGPIPE, SIG_IGN), dann liefern die IO Funktionen einen Fehler zurück, statt ein Signal auszulösen. Ich nehme an, dass die iostream-Klassen diesen Fehler weiterreichen. Aus der 'The GNU C Library' Dokumentation: Quote: If the reading process [...], writing to the pipe or FIFO raises a SIGPIPE signal. If SIGPIPE is blocked, handled or ignored, the offending call fails with EPIPE instead. Gruß, Hubert -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Torsten Robitzki Guest Posted: Wed Dec 31, 2003 12:16 pm    Post subject: Re: Scope bei Signalen Georg Maaß wrote: Quote: Wenn mein Programm von einem Signal getroffen wird, in was für einem Scope läuft dann der Signal-Handler? Insbesondere, wo muß ich ein try/catch hinschreiben, um eventuelle Exceptions, die so ein Signal-Handler werfen könnte, zu behandeln? Gehört das try/catch ins main, oder gehört es in den Programmzweig rein, in dem das Signal auftrat, oder kann man Exceptions von Signal-Handlern gar nicht fangen? Wenn ich z.B. über eine Pipe ein anderes Programm anquatsche, dann kann ein SIG_PIPE auftreten, das mir signalisiert, daß die Pipe abgestorben ist. Bisher habe ich dann einfach das Programm beendet. In einem Server jedoch kann ich ja wegen so einer Lapalie nicht den ganzen Server beenden, sondern da wäre mir eine Exception lieber, welche den Programmteil, der die Pipe nutzt, veranlasßt, mit einer Fehlermeldung abzubrechen, so daß der Server sich neuen Aufgaben widmen kann. Ich habe hier eine Dokumentation ([url]http://www.opengroup.org/onlinepubs/007904975/functions/write.html)[/url], nach der gibt write den Wert EPIPE zurück, wenn man mit write() versucht auf eine pipe zu schreiben, die kein lesendes Ende hat. Nach dem Du Deinen neuen Prozess geforked hast, solltest Du dem entsprechend das lesende Ende der pipe im Prozess schließen, so das es nur noch eine Referenz auf das lesenden Ende in dem neuen Prozess gibt. Solche Fragen würde ich aber mal in einer news group, in der mehr Experten für so etwas mitlesen, noch mal stellen. mfg Torsten -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Georg Maaß Guest Posted: Wed Dec 31, 2003 1:43 pm    Post subject: Re: Scope bei Signalen Torsten Robitzki wrote: Quote: Ich habe hier eine Dokumentation ([url]http://www.opengroup.org/onlinepubs/007904975/functions/write.html)[/url], nach der gibt write den Wert EPIPE zurück, wenn man mit write() versucht auf eine pipe zu schreiben, die kein lesendes Ende hat. Nach dem Du Deinen neuen Prozess geforked hast, solltest Du dem entsprechend das lesende Ende der pipe im Prozess schließen, so das es nur noch eine Referenz auf das lesenden Ende in dem neuen Prozess gibt. Solche Fragen würde ich aber mal in einer news group, in der mehr Experten für so etwas mitlesen, noch mal stellen. Ja, in der Form gehört es dann nach de.comp.os.unix.progamming -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Georg Maaß Guest Posted: Wed Dec 31, 2003 2:25 pm    Post subject: Re: Scope bei Signalen Thomas Maeder wrote: Quote: Na ja. signalled ist garantiert "signal proof". Ich würde davon ausgehen, dass das auch bedeutet, dass sie "thread proof" ist bei jeder vernünftigen Threads-Implementierung. Aber sobald wir über Threads schreiben, sind wir off-topic hier. Nein, denn in der realen Welt, in der C++ überleben will, kommen sie vor. Globalen Variablen die lediglich für einen Einzelthread gelten sollen, sind schlicht ein Witz, wenn sie keine Information enthalten, für welchen Thread sie gelten. sig_atomic_t ist ein stinknormaler int. Ich kann keinen Bezug eines int zu einem Thread erkennen, wenn dieser int nicht lokal ist. So ein globales Flag würde von allen Threads gleich interpretiert, was bedeutet, daß sie alle abbrechen und das Flag zurücksetzen. Der erste thread, der das Flag pollt, würde abbrechen und das Flag resetten. Wenn dann anschließend erst der Thread das Flag sieht, für den es eigentlich gedacht war, dann ist es bereits resettet, so daß er gar nicht erfährt, daß seine Pipe abgeröchelt ist, wohingegen der Thread, der zuerst das Flag gelsen hat, fälschlicherweise seine Pipe dichtmacht, weil er irrtümlich glaubt, seine Pipe wäre abgekratzt. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Marcel Müller Guest Posted: Wed Jan 07, 2004 2:32 pm    Post subject: Re: Scope bei Signalen Hallo, Georg Maaß wrote: Quote: Wenn ich z.B. über eine Pipe ein anderes Programm anquatsche, dann kann ein SIG_PIPE auftreten, das mir signalisiert, daß die Pipe abgestorben ist. Es ist nicht erforderlich diese Information in dieser Form abzufangen, da die Pipe, sobald das nächste mal darauf zugrgriffen wird einen Fehler erzeugt. Eventuell offene Zugriffe kehren sofort mit Fehler zurück. Also: read auf pipe, pipe stirbt => read kehrt mit Fehler zurück. Ähnliches gilt für connect. Bei rein ausgehenden Pipes wird der Fehler aber erst beim nächsten write bemerkt. -- Marcel Müller -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (German) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.