C: SIGUSR1, SIGUSR2, sigprocmask

L

lordosiris

Mitglied
Hallo,

ich habe mal wieder ein Verständnis Problem.

Und zwar komme ich ganz und garnicht mit SIGUSR1 und SIGUSR2 klar.

Rein Theoretisch wären es ja Benutzer Signale (1 & 2), rein von meinem Verständnis her wären das also Signale, die der Benutzer auf der Tastatur eingibt. Allerdings scheine ich damit wohl falsch zu liegen.

Ich habe mich jetzt mit Hilfe von Google erkundigt, wozu die beiden Signale verwendet werden, bzw. wie ich sie initialisieren und verwenden kann bzw. auf welche Arten, doch ich bin nicht schlauer geworden.

Genausowenig mit der Funktion sigprocmask.
Keine Ahnung was die macht, wozu, weshalb. Eine vernünftige Erklärung hab ich leider auch nicht gefunden.
Entweder bin ich Blind auf beiden Augen oder einfach nur zu blöd.

Vielleicht kann man mir das hier ja erklären.
 
Also SIGUSR1 und 2 sind Signale, die dem Entwickler zur freien Verfügung stehen. Kein Prozess löst sie direkt aus, sie müssten quasi manuell getriggert werden - eben durch deinen eigenen Code. Das macht man mit kill().

sigprocmask() kommt dann zum tragen, wenn man fork'ed oder Threads verwendet. Es dient dazu, dem Kind-Prozess entweder Signale unterzuschieben oder ihm vorzuenthalten. Ich finde die Erklärung im Gallileo OpenBook Linuxprogrammierung eigentlich recht gelungen: http://openbook.galileocomputing.de...ung/Kap08-010.htm#RxxKap08010040002721F024100

Vielleicht hilft dir aber ja das Beispiel weiter: http://openbook.galileocomputing.de...ung/Kap08-012.htm#RxxKap08012040002741F02B100
 
Es tritt erstmal gar kein Signal auf, wenn man was auf der Tastatur eingibt. Die eingegebenen Tasten werden im Keyboard-Buffer zwischen gespeichert, bis der entweder voll ist oder die Zeichen mit eine beliebigen Funktion (z.B. getchar()) abgeholt wird.

Du benutzt scanf, um auf eingehenden Input von stdin zu warten, der durch ein New-Line abgeschlossen wird. Der Vorgang ist blockierend.

Was für ein Typ hat den die Variable "input"?
 
Da hast du doch dein Problem. Du hast im Format-String ein "%s" angegeben, übergibst aber Pointer auf int (der noch nicht mal einen gültigen Speicherbereich hat - malloc() fehlt. Anschließend verwendest du wieder strcmp() um Strings zu vergleichen. Das muss schief gehen ;-)

Mach für input doch mal Character-Array mit der Länge von sagen wir mal 10:

C: 
char input[10] = {0};

Dann schauen wir weiter :)
 
Oh sorry, hab das ausm Kopf heraus geschrieben.

Ich hatte vorher nicht strcmp sondern einfach if(input==1).. Und da war input noch ein int.

Jetzt momentan ist es ein char *input.

Ich teste das mal mit char input[10]

E:/ so funktioniert's.
Obwohl ich mit dem, was SIGUSR2 machen soll, noch nicht ganz zurecht komme.
Wenn das erste mal SIGUSR2 gesendet wird, wird CTRL+C ignoriert. Wenn erneut SIGUSR2 gesendet wird, wird CTRL+C nichtmehr ignoriert.
Muss ich das nun mit sigprocmask machen?
 
Zuletzt bearbeitet:
Danke, ja, das wusste ich bereits.

Ich hab mir das jetzt folgendermaßen vorgestellt, das zu realisieren:

Wenn SIGUSR2 gesendet wird, wird usr2_handler ausgeführt. Dieser erstellt eine sigprocmask mit SIG_BLOCK, SIGINT. Somit ist ctrl + c geblockt. Anschließend setzt er signal(sigusr2,usr22_handler).

Kommt wieder ein SIGUSR2, wird jetzt nichtmehr usr2_handler sondern usr22_handler gestartet. Dieser verändert die sigprocmask dahingehend, dass SIGINT nichtmehr geblockt ist und setzt wieder folgendes: signal(sigusr2, usr2_handler).

Rein Theoretisch habe ich jetzt also genau das, was ich will:
Kommt beim ersten mal das sigusr2 signal, wird ctrl + c geblockt. Das solange, bis das sigusr2 signal wieder gesendet wird.

Jetzt meine Frage: geht das irgendwie eleganter?
Ich habs noch nicht gecoded, hab mir gerade Gedanken darüber gemacht, dann kam die E-Mail, dass du hier geantwortet hast. Das ganze programmiere ich jetzt mal

E:/ ****t natürlich nicht.
 
Zuletzt bearbeitet:
Ich möchte dir echt nicht zu nahe treten, aber meiner Meinung nach solltest du dich erstmal mit Grundlagen beschäftigen. Wenn jemand nicht den Unterschied zwischen char* und char[] kennt, sollte er nicht mit Betriebssystem-Interna wie Signalen beschäftigen.

Das ist echt nicht persönlich gemeint - nur ein gut gemeinter Rat. :)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück