times-aufruf

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.

times-aufruf
hi,

vielleicht bin ich zu bloed, aber wo ist hier der fehler:

ctps = sysconf (_SC_CLK_TCK);

times (&beforetime);
waitpid (id, &status, 0);
times (&aftertime);

fprintf (stderr, "Usertime: %li, Systemtime: %li\n", ((aftertime.tms_cutime - beforetime.tms_cutime)/ctps * 1000), ((aftertime.tms_cstime - beforetime.tms_cstime) / ctps * 1000));

ich krieg immer null raus, egal was ich mache. btw: was ist denn ein einfaches, rechenintensives kommando (tar uebersteigt immer meine cip-quota)?


tar doch einfach nach /tmp da hast du kein quota


Nimm sleep. Das ist zwar nicht rechenintensiv, braucht aber lang.
Weshalb multiplizierst du nachher noch mit 1000?


in den times steht aber drin wie lange das system damit beschäftigt war instruktionen für das programm abzuarbeiten getrennt in usermode und systemmode und ein sleep hat davon leider reichlich wenig


thx fuer den /tmp-tip.
die 1000 hab ich fuer die millisekunden genommen, und jetzt hab ich gerade festgestellt, das dass auch der fehler war: er hat erst durch ctps geteilt, dann kamm gerundet null raus, da bringt auch das mal 1000 nix mehr. wenn man die 1000 davor schreibt, dann gehts, zumindest braucht das taren meines homes 10ms user- und 200ms systemtime.
sind das realistische werte?


also bei mir dauert das ein bisschen länger weiss ja nicht wie gross dein home ist :wink:
machst du mit tar cvjf ? das j macht bzip2 kompression was auch nochmal schön rechnet, tar kopiert ja nur…


ok,
so schlau bin ich natuerlich nicht! gegendenkopfhau
ergebnis mit bzip:

12811     0       8:970   0:150 tar cvvjf /tmp/bla.tar /home/cip/2002/si******

so schreibt er es bei mir in die logdatei. passt das so?

edit: YEAH, ich sehe gerade, ich habe post #666 - wenn das mal kein gutes zeichen ist :gun: !


ja schaut ganz gut aus :slight_smile:


ok, dann kommt jetzt post #667 (the neighbor of the beast):

  1. wenn ein SIGINT kommt, dann bekommt ihn der vordergrundprozess auch
    und die hintergrundprozesse ignorieren ihn, bekommen dafuer aber ein SIGQUIT
    ==> auf jeden fall gibt mir keiner der prozesse einen exitstatus zurueck. ist das in diesem fall normal?

  2. @mikey: du hattest doch in der uebung gemeint, dass man procmask () braucht, um race conditions zu vermeiden. an welcher stelle soll man denn sowas brauchen, ich bin der festen meinung, dass MEIN programm das nicht braucht. kann das sein?


1.) Nein das ist nicht normal, du solltest die schon auflesen können.
Bei mir zB sieht das so aus:

mikey@lucifer:~/Uni/Hiwi/SP1/Muster/aufgabe5/bin.i386>./trsh 
trsh> sleep 1000 &
trsh> sleep 2000 &
trsh> sleep 10
Exitstatus [ sleep 10 ] = 0
trsh> jobs
[8500] sleep 2000 &
[8499] sleep 1000 &

Exitstatus [ sleep 2000 & ] = 0
Exitstatus [ sleep 1000 & ] = 0
trsh> 

wobei ich dir versichern kann dass ich keine 2000 sekunden gewartet habe und ich den sleep 10 durch einen Interuppt unterbrochen habe.

  1. es geht primär um diese jobliste. mit dieser wird dein inthandler ja wohl arbeiten wenn er allen kindern ein sigquit schickt und dazu die liste durchläuft um deren pids zu kriegen. wenn du nun an anderer stelle im programm auf der joblist arbeitest, musst du bedenken dass genau in diesem moment ein SIGINT kommen kann der dir dann die liste zerschiesst.
    deshalb musst du vor der arbeit auf der joblist das sigint blockieren und anschliessen wieder deblockieren. Wenn du mehrere signalhandler hast, ZB sigchld musst du natürlich auch das blockieren. Bei mehreren signalhandlern die auf der jobliste arbeiten ist zusätzlich zu beachten dass du alle anderen signale die solche handler haben auch zur laufzeit des signalhandlers blockierst (mit sa_mask in der struct sigaction).

(die prozesse werden bei den jobs noch angezeigt, weil ich meinen ghostbuster vor jedem prompt aufrufe und daher zum zeitpunkt der jobausgabe die jobliste noch nicht aktualisiert ist).


btw wenn du dein programm auf memory leaks testen willst solltest du das nicht mit der jobliste aus dem ~i4sp/pub machen die hat nämlich selber ein memory leak weil da ein free fehlt. In meinem wwwcip liegt eine ausgebesserte joblist.c :wink:


wenn du den rechner ohne much hassle™ zum schwitzen bringen willst, mach doch einfach

bzip2 < /dev/urandom > /dev/null


und wann terminiert das? :smiley:


ach ihr sucht was, das terminiert :heart:


ausserdem hat sicherlich nicht jedermann in seiner trsh die stdin und stdout umleitung eingebaut :wink:


mein gott, bin ich dumm! ich pruefe vorher mit dem WIFEXITED-makro, bevor ich den exitstatus ausgebe. da muss ich jetzt halt noch WIFSIGNALED hinzufuegen, denke ich.


hmm und was willst du dann ausgeben als Exitstatus? Ich prüfe auf sowas derzeit gar nicht :wink:

wobei meine trsh ein erfolgreiches Ende signalisiert was sicherlich nicht sinnvoll ist. Werde die Ausgabe wohl in Exitstatus=EXIT_FAILURE bei signalabbruch ändern


das hoff ich doch sehr, ihr koennt euch ja vorstellen, wie sich die Punkteverteilung aendert, wenn der Korrektor entsprechend genervt ist, weil er unnoetig viel lesen muss.

btw:
Je weniger Code, desto weniger potentielle Fehler, allerdings gilt das nimmer, wenn der Code undurchsichtig wird.


=)

ich hatte das nur falsch verstanden, dachte, da will wer was im Hintergrund laufen lassen, dass alles verlangsamt o.ä. ;))