Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Aufgabe 6: job_sh
Nix für ungut, aber mit der Aufgabenstellung zur job_sh und auch mit dem was man machen muss werd ich nicht wirklich glücklich.
Erstmal ewig den Kopf zerbrochen was GENAU jetzt gemeint ist.
Und mich dann gefragt, was die Aufgabe e) soll, weil ich mir da schon ne eigene queue basteln wollte, die meine ganzen gerade laufenden Sohnprozesse verwaltet. Brauch ich ja, um denen alle das Signal senden zu können.
Bis ich dann mal auf die f) geschaut hab und feststellen muss: Da soll ich ja nun letztendlich genau das machen. Eine kleine Jobverwaltung schreiben.
Darf ich mir das einfach schonmal vorziehen?
Soll ich es „unschön“ lösen, mit einem kill(0, SIGQUIT) und einem gleichzeitigen Verhindern, dass auch meine Shell damit SIGQUIT bekommt…?
Jetzt hab ich mal ins Forum vom Vorjahrgang geschaut und siehe da, damals kamen exakt die gleichen „Probleme“ auf.
Und was muss ich da lesen, geschrieben von juk höchst persönlich:
Hier zu finden (der ganze Thread ist interessant): http://fsi.informatik.uni-erlangen.de/forumtest/thread/3827,1#3316
Und nicht nur dieser Thread, auch noch andere in dem Forum zur job_sh.
Ja was ist denn jetzt passiert mit dem „ich hab’ s mir fuer’s naechste Jahr notiert.“ ? 
Also ich weiß ja nicht, aber die Aufgabe ist irgendwie beschi…nicht so toll
Vielleicht kann man wenigstens dann unserem Nachfolgejahrgang selbige leidige Geschichte ersparen? 
In Deinem Post kann ich als einzigen Kritikpunkt erkennen, dass Teilaufgabe e) vor der Teilaufgabe f) auftaucht - und die kannst Du ja vorziehen wenn Du willst. Bitte aber die vorgegebene Joblistenimplementierung verwenden (dieses Jahr gibts die glaube ich nur als Binaerbibliothek und nicht als Sourcefile so wie es in der Angabe steht).
Im uebrigen hat die “unschoene Loesung” auch ihre Vorteile, sie ist z.B. schneller und vermeidet ein paar Nebenlaeufigkeitsprobleme. Dafuer kann
der Shell eben ein QUIT Signal in der sehr kurzen Zeitspanne verloren gehen
das von “aussen” zugestellt wird. Obwohl wir die andere Loesung natuerlich lieber sehen wegen der dann noetigen Behandlung der Nebenlaeufigkeit wurde die andere Loesung immer als gleichwertig (sprich ohne Punktabzug) akzeptiert.
Warum die Aufgabe nicht geaendert wurde, kann ich Dir auch nicht sagen, aber in einem Jahr kann man sowas wohl schon mal vergessen…
Hast wohl recht, ja.
Aber das kann einem ganz schön Zeit kosten, wenn man versucht den roten Faden der Aufgabenstellung zu finden. Und einfach nicht weiß, wie das jetzt gemeint ist. Alles kein Stress mehr, wenn man einfach e) und f) herumdreht.
Es stand halt noch nicht bei uns im Forum und ich habs auch nicht in der Übung gehört, sprich zu wissen, dass es okay ist e) und f) herumzudrehen hilft sicher einigen weiter, die das hier lesen. Denn ich wusste nicht, dass das okay ist. Woher auch.
War doch keine bös gemeinte Kritik. Der juk darf das schon mal vergessen zu ändern, immerhin ist das SoS1 Team bis jetzt das coolste, was uns bis dato untergekommen ist. Musterlösungen drucken inklusive. Einfach zu geil 
Wobei ich auch bei Teilaufgaben vorher den roten Faden nicht ganz gefunden hab. Bin mir recht sicher, dass ich Aufgabe c) auch schon in Teilaufgabe b) gelöst hab. Ganz “unabsichtlich”. Aber ich glaub ich weiß schon, worauf die Frage bei c) abzielt, insofern kein Stress.
Hi,
also ich bin auch grad dabei und mir gehts mit Aufgabe c) ähnlich wie dir. Wenn ich meinen Prozess in den Hintergrund schicke, läuft die job_sh ja ganz normal weiter, d.h. sie kann den Exitstatus des Kindprozesses gar nicht wissen => sie wird ihn auch niemals anzeigen, weil sie nicht mitkriegt wann der beendet. Ganz lustig dabei ist z.B. der ls Befehl, weil der seine Ausgabe dann einfach mal mitten rein streut, d.h. es kommt sofort das prompt symbol wie gefordert und gleich hinterher die ls Ausgabe, weil die halt etwas langsamer war…
Worauf die Aufgabe abzielt is mir grad im Moment nicht ganz klar, vielleicht kannst du mir ja einen Tipp geben?
Gruß Andi
Das der ls seine Ausgabe in die Shell streut ist fuer eure Shell ganz normal. Zum Testen von Hintergrundprozessen eignet sich am Besten der Befehl sleep der keine Ausgabe verursacht und eine Weile laeuft.
Dass ein Kind stirbt kriegt Dein Prozess schon mit, das wurde in den Tafeluebungen diese Woche behandelt (Stichwort SIGCHLD).
Worauf die Aufgabe abzielt? Siehe Uebungsfolie U7.2
Doch, dann bekommt sie nämlich ein [m]SIGCHLD[/m], und du kannst mit [m]waitpid()[/m] (–> nicht blockierend!) alle angefallenen Zombies abarbeiten.
ok dann hätt ich wohl mal besser die Übungsfolien nochmal angeschaut… Danke, dann versteh ich die sache auch
Also in den Teilaufgaben vor Aufgabe e) und f) interessieren mich im Hintergrund angefallene Zombies noch recht wenig?
Sprich nach Aufgabe c) schauts halt so aus, dass Prozesse, die in den Hintergrund geschickt wurden dort solang laufen, bis sie zum Ende kommen und damit zum Zombie werden.
Was mich nicht weiter stört.
Erst ab e) und f) wird sich der “Problematik” dann zugewendet.
Richtig, in c soll lediglich sichergestellt werden, dass immer der Status des Vordergrundprozesses ausgegeben wird.
Die Teilaufgaben waren eigentlich ursprgl. als reine Hilfestellung gedacht um
die doch umfangreiche Aufgabe in kleinen Schritten bearbeiten zu koennen. Klar, dass ihr euch nun mehr an die Teilaufgaben klammert nachdem sie als RCS Versionen eingecheckt werden sollen… Aber auch hier gilt, dass wir euch
nur zur Verwendung von RCS zwingen wollen. Daher denke ich, dass es auch keinen Punktabzug gibt, wenn man anhand der RCS Datei sieht, dass ihr RCS verwendet habt um einzelne Zwischenstaende der Bearbeitung abzulegen (und das ist dann i.d.R. auch eine sinnvollere Benutzung als die Eincheckung der einzelnen Teilaufgaben).
[size=9]
P.S.: Glaubt ihr wirklich, wir versechsfachen unseren Korrekturaufwand um
zu pruefen, ob ihr auch wirklich einzelne RCS Releases entsprechend den
Teilaufgaben eingecheckt habt??
[/size]
Also ich würds so machen 
lol
könnte es eigentlich sein, dass libjl.a auf einer 64-bit Maschine nicht läuft?
Das kann durchaus sein, dass die nicht 64 bit kompatibel sind, genaueres kann dir nur der Autor sagen. Es sollte doch kein Problem sein, das mal im cip auszuprobieren oder? Hab zwar noch nix damit gemacht aber mit ‘-m32’ muesste der compiler auch 32 bit code erzeugen, der muesste auch aufm 64bit proz laufen im Kompatibilitaetsmodus. Das musst du natuerlich fuer deinen code anwenden, der andere wird ja nur noch dazu gelinkt, als einfach an die CFLAGS anhaengen.
Und bitte bitte bitte bitte bitte bitte nehmt diesen RCS-Zwang wieder raus.
Ich denke es hat inzwischen jeder verstanden, wie toll so ein RCS doch ist.
Aber ich würde wieder gerne mit meinem darcs (und andere bestimmt wieder mit ihrem SVN) arbeiten.
Und immer das RCS ins darcs einchecken ist auch für’n Arsch.
mit -m32 - Option hat’s tatsächlich kompilliert 
Seufz…
:-/ - ich hab’ die Notiz gefunden…
ansonsten kann ich mich nur meinen Aeusserungen vom letzten Jahr anschliessen
Wir werden die Aufgabe in den naechsten Tagen neu formulieren und
im Aufgabedirectory fuer 2007 abspeichern - das ist wohl die sicherste
Methode damit uns das nicht nochmal passiert. Vorsaetze von einem
auf’s naechste Jahr sind halt doch eine kritische Angelegenheit…
Die letzten beiden Wochen waren reichlich stressig und
wenn’s an zig Stellen brennt, dann ist man froh, wenn man die
Aufgabenstellung ueberhaupt raus bringt und da flutscht sowas natuerlich
ganz schnell durch.
Aber so 'ne Foren-Historie hat schon was
toll, ich such’ demnaechst uebungsleiter fuer die Aufgabenkorrekturen 2007… :-p
hahaha geil das wort im mund umgedreht
warum, man macht des ja net umsonst
für 500€ im semester auf jeden fall wo muss man unterschreiben? 