[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lost] [Patch] Signale



Toni Kaufmann schrieb:
Hier ein Patch der LOST die wichtigsten Funktionen für Posix-Signale
beibringt. Dabei wird der bisherige signal-Syscall entfernt. Die  neue
implementierung funktioniert über send_message.

Für Signale sind aber explizit die Funktionsnummern 256 bis 511 freigehalten. Ich halte es für eine schlechte Idee, die jetzt nicht zu nutzen, sondern stattdessen einen nutzlosen Stringvergleich einzubauen und die correlation_id zu mißbrauen.

Für diesen teil daher ein klares NACK.

+/// LOST-Spezifisches Signal: Eingabedaten auf Terminal bereit
+#define SIGTERMINPUT 31

Wollen wir Signale wirklich aktiv nutzen und nicht nur für die POSIX-Kompatibilität halbwegs abbilden? Für LOST-interne Sachen würde ich einen normalen RPC bevorzugen (wobei mir ohnehin nicht klar ist, wofür dieses Signal gut ist)

+/// Nur fuer interne Verwendung. Muss immer 1 groesser sein als die groesste
+/// Signalnummer und teilbar durch 8
+#define _SIGNO_MAX 64

Nur für interne Verwendung heißt, daß es in die .c-Datei gehört.

+void _signal_default_handler(int signum)
+{
+    printf("Signal %d\n", signum);
+
+    switch (signum) {
+        // Signale die den Prozess mit Schnickschnack wie Core-File beenden
+        // (TODO)
+        case SIGQUIT:
+        case SIGILL:
+        case SIGTRAP:
+        case SIGABRT:
+        case SIGBUS:
+        case SIGFPE:
+        case SIGSEGV:
+            // Hier koennte man jetzt jede Menge debug-Zeug einbauen wie
+            // core-Dumps und sowas ;-)
+            // Und das break fehlt hier auch absichtlich!

Könnte man zwar machen, aber wäre eher nutzlos, denn der Kernel sendet nicht groß Signale, sondern killt den Prozeß einfach. ;-)

+/**
+ * Handler fuer ein ignoriertes Signal
+ *
+ * @param signum Signalnummer
+ */
+void _signnal_ignore_handler(int signum)
+{
+}

Unnötig, wofür gibt es NULL?