Wie gesagt wahrscheinlich wird nichts schiefgehen, aber undefiniert heist halt das der Compiler und das System in so fällen theoretisch alles machen dürfte.
Was tatsächlich hier "richtiger" wäre, wäre es den Wert zu überschreiben (mit True) und danach einen neuen Signal Handler zu registrieren der dann den wert mit False überschreibt beim nächsten call. Das klingt vielleicht umständlich und unnötig, ist aber standard konform.
Oder man registriert einfach 2 Handler, einen zum einschalten und einen zum ausschalten. (Man kann übrigens auch noch viel mehr Signale als SIGUSR1 und 2 der standard stellt nur ein Mindestmaß an reservierten signalen da, aber spezifiziert das Plattformen beliebig mehr signale setzen dürfen, welche alle auf dem system erlaubt sind kann über ein C makro festgestellt werden)
Der Grund warum das so im standard steht ist eigentlich relativ einfach, der Standard will nicht unnötig einschränken wie Signale von der Plattform implementiert werden, so sachen wie, was passiert wenn mehrere Signale gequeued werden, wie die abgearbeitet werden, Z.B. bei GLIBC über Stackframes, da wird für jedes austehende signal rekursiv ein Stackframe gepusht und beim return wird dann das nächste signal abgearbeitet (das hat übrigens den sehr schönen seiteneffekt das du signalhandler von schon getriggerten signalen nicht mehr ändern kannst, da der lookup beim recursiven descent bereits gemacht wurde).
Was das auf jeden fall bedeutet ist, das du nicht unbedingt sicher sein kannst in welcher reihenfolge signale ausgeführt werden, wann sie auftauchen, und vor allem wenn signale andere signale unterbrechen (und wenn ausmaskiert sind wie sie gequeued werden).
Außerdem werden Signale richtig spaßig wenn man auf mehreren Threads arbeitet, da signale single threaded sind, aber man keine garantie hat auf welchem thread ein externes signal gefeuert wird.
Hier sollte im grunde nichts passieren können weil die anwendung single threaded ist, das auslesen atomar ist, und da sigaction benutzt wird, das signal sich nicht selbst unterbrechen kann (was bei z.B. "fpsignal" nicht unbedingt der Fall wäre, obwohl wahrscheinlich signal intern sigaction aufruft, kann es sein das es was das angeht sich anders verhält).
Aber wie gesagt, wenns um undefiniertes Verhalten geht, kann man keine garantien geben. Das gesagt, da halten sich auch nicht alle dran, wie man beim
gnu disk-destroyer source schön sieht, hält sich nicht mal GNU dran:
Code: Alles auswählen
static void
siginfo_handler (int sig)
{
if (! SA_NOCLDSTOP)
signal (sig, siginfo_handler);
info_signal_count++;
}