Re: [Lost] [Patch] Signale

[Kevin Wolf <mail@xxxxxxxxxxxxx>]

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?