sleep(60*60*24)

Jeg havde en sjov diskussion med en bekendt, det handlede om lange sleeps.

Forestil jer en process der holder styr på et eller andet underligt og som beslutter sig for, at der ikke ser ud til at ske noget det næste døgn.

Allright: "sleep(606024);" ?

Her overraskede jeg min bekendte ved "kun" at sleep'e ti minutter ad gangen, for derefter at vågne op og finde ud af at der nok stadig ingenting sker foreløbigt og så sove 10 minutter mere.

Der er tre årsager til at jeg gør det på den måde:

  1. Der er ret mange systemer hvor uret ikke går rigtigt. Hvis uret bliver stillet, af NTPD eller med tastaturet, er det pludselig ikke sikkert at der er et helt døgn til at der sker noget.

Andre forudsætninger kunne være fejlbehæftede på samme vis. Hvis processen laver en sleep på et helt døgn, er man reelt nødt til at skyde den ned og genstarte når problemet er rettet, når den kun sleep'er 10 minutter, retter det sig selv.

  1. Man kan se at processen er på plads og i orden, f.eks med ktrace(1), strace(1) eller lign.

  2. Det giver operativsystemet en lejlighed til at flytte rundt på ting der vedrører processen, hvis der er behov.

Tænk over det...

phk

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anonym

Jeg bruger selv korte sleeps, typisk 1/100 del af det angivne interval.

Ud over sleep ikke 'koster' noget, så opnår man muligheden for at lave en kontrolleret nedlukning/messagehandling med 'schedulertråden'.

Det gælder især Windows services, men også NPTL under Linux, der ikke er signaldrevet.

  • 0
  • 0
Søren Koch

Ja jeg bruger også korte sleeps (ofte a 5 sekunders varighed) men det er fordi de målinger de systemer jeg vedligeholder kan tage alt fra 2 minutter til 5 timer (Frekvens-respnose analyse) og de Solartroner vi har svarer nogen gange ikke helt som de skal hvorfor man kan være nødt til at gentage en måling, så for at finde ud af hvornår en målig er helt færdig er man bare nødt til at spørge 'er du færdig?' og så se om det er tilfældet, så derfor sleep(5) og check, repeat.... :-)

  • 0
  • 0
Kai Birger Nielsen

Minder mig om en gang hvor folk syntes at min kode var paranoid. Et system (dos?) hvor der kun var separate systemkald til hentdato og henttid. Jeg pakkede henttid ind i en whileløkke, så jeg var sikker på at henttid og hentdato ikke gav mig resultater fra to forskellige datoer. Lidt aftestning viste at ikke alle systemkommandoer var lige så paranoide :-(

  • 0
  • 0
Anonym

Minder mig om en gang hvor folk syntes at min kode var paranoid

Hmm. DOS og henttid ? Så vidt jeg husker skulle man selv taste dato og tid ind ved opstart på de gamle 8086-æsker, da der ikke var noget batteri backup.

Kommer lige i tanke om, at jeg har en gammel 'dampkoger' (IBM/XT), og den starter op med 1/1/1980 og 0:0:0.

Jeg startede den op og tog et billede, men billede,blitz og CRT - hmm. http://w-o-p-r.dk/images/xt.boot.jpg

Men bortset fra det ville jeg nok også synes din kode virker paranoid - hvis den alligevel er baseret på et arbitrært input fra et menneske :-)

  • 0
  • 0
Anonym

ganske fornuftig hensyn til tiden omkring midnat

Ja, enig - det slog mig at han måske mente hente tid og dato separat, men da havde jeg selvfølgelig klikket på send.

Jeg kan ikke huske hvordan vi satte og hentede tiden i 'DOS'.

Dengang var DOS nærmest ubrugeligt, så jeg kunne forestille mig det var via Assembler til BIOS, ligesom styring af Skærm/Tastatur/Net.

Jeg mindes ikke at have været ude i et system hvor man ikke opererer med 'datetime', men kun date og time.

Det er også muligt jeg misforstår hvad der bliver skrevet.

  • 0
  • 0
Carsten Hess

Det har altid været god og defensiv kodeskik at checke oftere end egentlig påkrævet, som PHK korrekt påpeger. Dog er jeg ikke tryg når jeg f.eks. læser Stig ovenfor skrive at han typosk venter 1/100 af intervallet... for det kan meget let lede til alt for høje polling-frekvenser, der holder cpuen aktiv, når den burde sove. Specielt hvis den der har stillet kravet om hvor længe der skal "soves", selv har reduceret med sin egen faktor.

Adskillige applikationer vækker en moderne CPU hele tiden, ved at polle alt, alt for ofte (som man evt. kan læse mere om her: http://www.lesswatts.org/projects/index.php ) udover at ødelægge batterilevetiden på ens laptop, er det heller ikke sælig "grøn" kode, noget vi alle burde begynde at tænke mere over!

Så selv om jeg er enig i at det er skidt at sove for længe (på alle måder), kan jeg ikke blindt slutte op om altid at vække applikationen oftere, bare fordi man kan.

  • 0
  • 0
Morten Fordsmand

Som jeg husker skyldtes problemerne med de tiden på de første PC'er (sådan cirka præ-AT)at der ikke var et indbygget ur i hardware, hvorfor DOS ved IPL var nødt til at bede brugeren om det rette tidspunkt.

Dette betød i øvrigt at man var nødt til at sætte tiden i BIOS eller med en utility, indtil DOS kunne understøtte opdatering i af BIOS-tiden, og der gik vist et par releases før det var på plads.

  • 0
  • 0
Anonym

Dog er jeg ikke tryg når jeg f.eks. læser Stig ovenfor skrive at han typosk venter 1/100 af intervallet

Du behøver ikke føle dig utryg.

Der er tale om integrationsservices/propagation services, der kører 24/7.

I virkeligheden burde det være evemtdriven, men man kan ikke altid trigge en event fra en 'mainframedatabase' mod en middlelayer Win´´-server.

Men som sagt, det virker i praksis, så don't worry.

  • 0
  • 0
Log ind eller Opret konto for at kommentere