das sollte kein kriterium sein für polling.
dann doch eher den exitstatus zurückhalten und bei der richtigen gelegenheit ausgeben.
warum denn nicht, bzw was is daran so schrecklich?
das würde aber einen netten Mehraufwand darstellen der IMHO nicht gerechtfertigt ist
btw was ihr macht ist natürlich euch überlassen auf Schönheit der Ausgabe wird bei der Korrektur keiner schaun
Ich würd’s auch wie bei der bash machen … dort wird scheinbar direkt bevor der prompt erscheint auf tote kinder überprüft …
per signalhandler die kinder aufsammeln und deren exitstatus “an geeigneter stelle” ausgeben ist wenig sinnvoll. Man muss das dann noch extra zwischenspeichern und welche andere Stelle als die oben genannte ist denn noch geeignet? 
na sehr gut, ich sammel naemlich die zombies immer erst ein, wenn der benutzer ein return gedrueckt hat. das zaehlt zwar auch als polling, ist aber nicht wirklich ineffizient.
ha, das freut mich jetzt, dass ich auf den signalscheiss verzichten kann.
naja ineffizient ist es nicht, da jedesmal auf Verdacht einen wait zu machen, zumindest vertretbar, weil ja eine Benutzereingabe eh viel laenger dauert.
Ein Problem kann des ganze geben, wenn man nen ganzen Friedhof erzeugt hat und seine Zombies im System rumgeistern, und der Benutzer par tout keine Benuztereingabe mehr macht.
Eine Ausgabe wuerd ich im Signalhandler auch net machen, sondern die Daten in eine globale Struktur uebergeben, dazwischenschreiben ist net grad die feine englische Art.
So machens auch die ueblichen shells, ich faends aber net tragisch, wenn des jemand mit polling macht.
:finger: Auf was ihr aber achten muesst ist, was passiert, wenn die shell abgebrochen wird, da duerfen keine Zombies uebrig bleiben.
Mikey: Ich finde nur die Argumentation etwas seltsam, denn ob ich Polling verwende oder nicht damit zu entscheiden, wann ich was ausgeben will…
wenn das Polling auf einen Select hinausläuft, ist es ja prinzipiell in ordnung…
ok vergesst das in der Aufgabenstellung taucht die Formulierung auf, dass ihr UNMITTELBAR nach terminieren eines Childs den Record schreiben muesst, also wird man um das SIGCHLD nicht rumkommen…
Also laut WaWi (Christian Wawersich) muss ein SICCHILD-Handler installiert werden, da sonst, wenn ich z.B. 20 Hintergrundprozesse starte, anschliessend den PC fuer 2 Wochen verlasse und wieder zurueck an meine Shell komme 20 Zombies (unter der Voraussetzung, dass ich Polling mache) da sind, die nicht von der Shell aufgelesen worden sind.
Ausserdem machen wir das ganze mit der Jobverwaltung als Liste nur, damit Nebenlaeufigkeit mit ins Spiel kommt, sprich Race-Conditions, die ihr natuerlich geschickt umschiffen sollt.
folgendes Problem kann entstehen, wenn man sich nicht angewoehnt, die Zombies unmittelbar aufzulesen:
frahi@nb2000:/tmp > cat forkbombe.c
int main() {
while(1){
if(fork()==0) {
exit(1);
}
}
}
frahi@nb2000:/tmp > ./forkbombe &
[1] 17259
frahi@nb2000:/tmp > ls
-bash: fork: Resource temporarily unavailable
frahi@nb2000:/tmp >
Must du forkbombe.c nicht zwischendurch auch kompilieren ? 
Auf den Übungsfolien steht: “Es wird maximal ein Signal zwischengespeichert”. Siehe Link, Folie 10.
http://www4.informatik.uni-erlangen.de/Lehre/WS03/V_SP1/Uebung/folien/G-Uebung5-A6.pdf
Laut Übungsleiter und Folie erzeugen also, wenn 4 Kinder gleichzeitig sterben, nur Kind 1 und 2 ein SIGCHILD.
Falls das tatsächlich so ist (ich hab nix in den Manpages dazu gefunden) , ist es mir schleierhaft, wie man die Aufgabe dann sauber mit SIGCHILD Signalhandler lösen soll, wenn man immer damit rechnen muss, dass Signale versickern.
klar, aber du kannst ja solange im handler waitpid mit WNOHANG ausführen bis du irgendwann ne 0 als Rückgabe hast und damit alle Zombies auflesen die bis dato angefallen sind…
Im System existiert eine Bitliste, in dem fuer jedes Signal (also jede Art von Signal, z.B. SIGCHLD, SIGINT) ein Bit existiert, also gesetzt oder nicht gesetzt.
Deshalb kann,wenn ein Signal ankommt, blockiert wird und noch eines kommt, dieses Bit nur gesetzt bleiben. Man kann also im Signalhandler nicht unterscheiden, ob das Signal nun einmal oder oefter gekommen ist.
Deshalb muss die Semantik von dem sigchildhandler auch: „Hole alle Childs, die im gestorben sind“ sein.
2 Signale unterschiedlichen Types wenn kommen, stoeren die sich nicht gegenseiten, es gibt ja jeweils ein Bit, dann werden die beide bearbeitet.
gesetz dem fall meine shell wartet auf ne Eingabe. Währenddessen stirbt ein Hintergrundprozess und mein child-handler knallt mir den Exitstatus rein. Bei der Muster-trsh-Fassung beendet sich dann die trsh da sie ein EOF und dazu den stdin-ferror “Interrupted System call” liest. Weiss jemand woran das liegen kann?!
muster-trsh??
die muster-mysh hat garkeine im & ausführen funktion.nicht böse sein, aber ich glaube den fehler hast du selbst zu verantworten…
wenn du magst kannst ja heute mal ins cip kommen (2. stock) da wern der q und ich unsere trash fertig coden.
Muss man eigentlich die signale SIGCHLD und SIGINT blockieren, wenn man mit der joblist arbeitet? Wenn ja, wie werden dann die evtl in der zwischenzeit blockierten signale behandelt?
gruesse,
ja muss man,
jedes Signal kann waehrend es blockiert ist nur einmal als ankommen markiert werden,d.h. wenn 2 SIGCHLDs kommen waehrend SIGCHLD blockiert ist, ist nur gesetzt, dass eines gekommen ist. Wenn man die Signale deblockiert, werden die als gekommen gesetzen Signale abgearbeitet.
D.h. dass z.B. der Signalhandler fuer SIGCHLD auch mehrer Kinder abholen koennen muss, oder gar keines.
D.h. man muss mit dem sigprocmask halt SIGCHLD und SIGINT blockieren und wieder deblockieren, sonst nichts. Die verpassten Signale kommen automatisch wieder an?
genau
woran lags denn, ich hab das problem auch