GEMDOS

Programmstart und TPA

gemdos-Trap

5.7 Signale

Das aus der U*NIX-Welt stammende Signal-Konzept steht auch unter den Betriebssystemen MultiTOS und MagiC (ab Version 4.50) zur Verfügung. Signale können als natürliche Zahlen aufgefaßt werden, die einen bestimmten Ausnahmezustand (Exception) repräsentieren. Sie sind mit einem Interrupt oder einer CPU-Exception vergleichbar, mit dem Unterschied jedoch, daß es sich um eine reine Software-Implementation handelt.

Jeder Prozess besitzt:

• einen Bitvektor der wartenden Signale (pending Signals). Dieser beschreibt diejenigen Signale, die noch auf ihre Bearbeitung warten, weil sie z.B. gerade durch die Signalmaske gesperrt sind, oder weil der Prozess in einem Zustand ist, in dem er keine Signale bearbeiten kann.
   

• eine Signalmaske. Dieser 32bit-Wert definiert als Bitvektor diejenigen Signale, die momentan gesperrt sind; wenn in diesem Vektor z.B. Bit-30 gesetzt ist, ist das Signal SIGUSR2 gesperrt. Die Signalmaske wird nicht nur explizit (d.h. durch Systemaufrufe), sondern auch implizit durch andere Vorgänge beeinflußt. Während der Abarbeitung eines Signals ist dieses z.B. gesperrt, andere können jedoch noch auftreten. Nach der Bearbeitung des Signals wird dieses wieder freigegeben und damit evtl. eine weitere Signalbehandlung ausgelöst. Beachtet werden muss, daß einige Signale (z.B. SIGKILL, SIGSTOP, SIGCONT) nicht maskiert werden können.
   

• eine Tabelle der Form struct sigaction
   

Bei einem Pexec werden die Signalmaske und der pending-Wert (s.o.) des Child-Prozesses auf Null gesetzt. Die Komponente sa_handler der sigaction Struktur wird vererbt, wobei ein Wert ungleich 0 oder 1 immer auf 0 gesetzt wird. Die Komponenten sa_mask und sa_flags der Struktur werden auf den Wert Null gesetzt.

Die meisten Signale können von einem Programm abgefangen, (um etwa beim Eintreffen eine bestimmte Routine aufzurufen) ignoriert, oder auch blockiert werden. Blockierte Signale werden solange nicht berücksichtigt, bis die Blockade wieder aufgehoben wird. Zur Terminologie: Man sagt, daß ein Signal zu einem Prozess geschickt wird, wenn die das Signal repräsentierende Exception auftritt, oder wenn das Signal per Pkill von einem anderen Prozess gesendet wird. Ein Signal wurde hingegen an einen Prozess überbracht, wenn der entsprechende Prozess aufwacht, und die für das Signal passenden Aktionen einleitet. Zu beachten ist, daß das SignalHandling nicht zeitlos geschieht: Zwischen dem Abschicken eines Signals, und der Aufnahme der dazu passenden Aktionen kann evtl. ein beträchtlicher Zeitraum verstreichen.

Insgesamt stehen 31 mögliche Signale (0 bis 30) zur Verfügung, denen aber noch nicht allen eine feste Bedeutung zugewiesen ist. Die folgende Liste beschreibt (soweit bekannt) alle möglichen Signale in der Form: Signalnummer, Name des Signals, Bedeutung des Signals für den empfangenden Prozess. Sofern nicht ausdrücklich anders beschrieben, besteht die Default Aktion beim Eintreffen eines Signals in der Terminierung des empfangenden Prozesses.

Querverweis:
Signalhandler in MagiC   Prozessfunktionen   Beispielcode   Psigaction   Psignal   Pkill   Test auf Pipes

5.7.1 Signalhandler in MagiC

Da sich Signalhandler in MagiC etwas von denen in MiNT bzw. MultiTOS unterscheiden, wird an dieser Stelle auf die wichtigsten Unterschiede bzw. Eigenschaften eingegangen. Zunächst einmal muss festgestellt werden, daß in MagiC AES- und VDI-Aufrufe aus einem Signalhandler heraus erlaubt sind (ganz im Gegensatz zu MiNT).

Ein Signalhandler läuft im Usermodus und verwendet den Userstack des Haupt-Threads, der solange schläft. In MiNT wird der Supervisor-Stack des Prozesses verwendet. Daher schießt laut MiNT-Dokumentation die Verschachtelung von Signalen ab 4 Stück einen Prozeß wegen Stapelüberlaufs ab. In MagiC ist jeder Signalhandler ein eigener Thread mit eigenem Supervisor-Stack, es kann also lediglich der extrem unwahrscheinliche Fall des Userstack-Überlaufs eintreten. Wenn jedoch zur Behandlung eines Signals zuwenig Speicher für einen neuen Thread zur Verfügung steht, wird eine Alertbox "System hat keinen freien Speicher mehr" ausgegeben, und es sollte schleunigst ein Programm beendet werden. Für jede Signalbehandlung benötigt MagiC ca. 7k Speicherplatz.

Für Signale gilt in MagiC das gleiche wie für Threads (ein Signalhandler ist ein Thread), d.h. die entsprechenden Systembibliotheken müssen reentrant sein. Es kommt jedoch noch erschwerend hinzu, daß der Haupt-Thread während der Abarbeitung des Signals angehalten wird. Wenn also der Haupt-Thread eine Semaphore (Stichwort: wind_update) gesetzt hat, ensteht ein Deadlock, wenn der Signalhandler diese Semaphore ebenfalls setzen will. Weiterhin kann ein Prozeß in MagiC an beinahe beliebiger Stelle unterbrochen werden (MagiC ist reentrant, sogar DOS ist unterbrechbar), so daß der Haupt-Thread u.U. wichtige Bereiche des Systems sperrt (Dateien, Verzeichnisse, Semaphoren). Daher kann es z.B. vorkommen, daß bestimmte Dateien nicht gelöscht oder geöffnet werden können.

Beim normalen Beenden eines Signalhandlers werden alle von dem Handler gesperrten Semaphoren automatisch freigegeben. Weiterhin werden ggf. Fenster, Bildschirmhintergrund und Menüleiste des Signalhandlers freigegeben. Man beachte, daß ein Signalhandler eine eigene AES Message-Queue besitzt, d.h. evnt_message und appl_write sind mit Vorsicht zu verwenden.

Bei Psigreturn werden die Semaphoren aller Signalhandler als auch die des Haupt-Thread freigegeben. Nicht freigegeben werden jedoch Fenster, Bildschirmhintergrund und Menüleiste der Signalhandler. Das wäre zwar kein großes Problem gewesen, dürfte aber in der Praxis nicht notwendig sein. Psigreturn restauriert den Supervisor-Stack des Haupt-Thread, d.h. ein setjmp/longjmp-Mechanismus braucht nur den USP zu setzen. Dies ist in der MiNT-Dokumentation nicht ausreichend dokumentiert und funktioniert auch nur dann, wenn der Haupt-Thread per GEMDOS-Aufruf wartet. Kommt AES ins Spiel, stürzt MultiTOS ab. Psigreturn sollte daher nach Möglichkeit vermieden werden. Psigreturn ist in MagiC nicht vom Typ VOID wie in MiNT, sondern vom Typ LONG. Wenn die Funktion von einem Nicht-Signalhandler aufgerufen wird, liefert Psigreturn den Wert EACCDN zurück, sonst E_OK. Hat Psigreturn E_OK geliefert, sollte (wie in MiNT) auf keinen Fall die Behandlungs-Prozedur normal per rts beendet werden, weil die Rücksprungadresse auf dem Userstack nach der Ausführung von Psigreturn ungültig ist.

Ein Problem existiert in MagiC mit den bisherigen Versionen von VT52. Ein Signalhandler kann noch keine Tastaturabfragen im VT52 durchführen; die Tasten werden noch nicht empfangen. Dies wird sich in einer späteren Version jedoch noch ändern.

Querverweis: Prozessfunktionen   Signale   Threads

5.7.2 Beispielcode zu Signalen

Das erste Programm installiert einen Signalhandler für die beiden Signale SIGUSR1 und SIGUSR2. Damit kann man die Verschachtelung der beiden Signale testen, wenn beide hintereinander verschickt werden. Das Programm sollte im VT52 bzw. im MINIWIN laufen. Wenn man während der "for()" Warteschleife Ctrl-Alt-Esc betätigt, erkennt man, daß MagiC für jeden Signalhandler einen eigenen Thread erstellt. Das hat den Vorteil, daß unter MagiC keine Ereignisse (Maus, Timer, ...) verlorengehen können, während ein Signal bearbeitet wird.

------------------------------ schnipp --------------------------
#include <tos.h>
#include <stdio.h>

void cdecl handler(long signr)
{
    long i;

    printf("handler: Signal %ld empfangen.\n", signr);
    Cconws("warte...");
    for (i = 0; i < 7000000L; i++)
        ;
    Cconws("...OK\r\n");
}

int main( void )
{
    long ret;

    printf("Meine ProcID ist %d.\n", Pgetpid());
    ret = (long) Psignal(SIGUSR1, handler);
    printf("Psignal => %ld\n", ret);
    ret = (long) Psignal(SIGUSR2, handler);
    printf("Psignal => %ld\n", ret);
    Cconin();
    return(0);
}
------------------------------ schnipp --------------------------

Das zweite Programm zeigt die Behandlung des Psigreturn()-Aufrufs. Unter MiNT funktioniert dieses Programm nur, wenn man keine AES-Aufrufe (evnt_keybd() oder evnt_multi()) verwendet, sondern z.B. Cconin() verwendet. D.h. das folgende Programm funktioniert unter MagiC und stürzt unter MultiTOS (MiNT 1.08+AES 4.1) ab. Das Problem liegt wahrscheinlich an der Restauration des Supervisor-Stacks (Systemstapelzeiger), dabei versagt MultiTOS wegen des inhomogenen Konzepts AES<->MiNT.

------------------------------ schnipp --------------------------
#include <tos.h>
#include <aes.h>
#include <setjmp.h>
#include <tosdefs.h>
#include <stdio.h>

jmp_buf env;

void cdecl handler(long signr)
{
    printf("handler: Signal %ld empfangen.\n", signr);
    Cconws("Mache Psigreturn()\r\n");
    Psigreturn();
    longjmp(env, 1);
}

int main( void )
{
    long ssp;

    appl_init();
    printf("Meine ProcID ist %d.\n", Pgetpid());
    Psignal(SIGUSR1, handler);

    if  (setjmp(env))
        Cconws("komme von longjmp.\r\n");
    else    Cconws("komme von setjmp.\r\n");
    ssp = Super(0L);
    Super((void *) ssp);
    printf("ssp = 0%08lx\n", ssp);
    evnt_keybd();
    return(0);
}

Querverweis: Signale   Prozessfunktionen   GEMDOS

GEMDOS

Programmstart und TPA

gemdos-Trap