Topic       : TOS - das Betriebssystem
Author      : 
Version     : tos.hyp (5. März 2013)
Subject     : Programmieren/Atari
Nodes       : 3001
Index Size  : 93602
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Titel
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File5.7.1  Signalhandler in MagiC                                      TOS

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