Omstart? Aldri mer

[Theo343]

 

Må forøvrig flire litt av denne

Kjenner dårlig til historien bak LLVM, men hvis du tenker på BSD er det verdt å få med seg PCC vs. GCC kontroversen med Theo de Raadt i spissen. Verden hadde vært mye kjedeligere uten Theo, apropos folk som tiltrekker seg oppmerksomhet.

Var egentlig et sleivspark fra min side.

Endret 2. juli 2009 av Theo343

[fenderebest]

Poenget mitt går åpenbart ikke igjennom, jeg har bedre ting å gjøre og oppgir denne diskusjonen.

 

 

Problemet er egentlig tatt fra en gammel bok angående operativsystemdesign og synkronsiering. Såvidt jeg vet har den ingen praktisk god løsning men om du er interessert i å fortsette denne debatten foreslår jeg vi gjør det over PM slik at vi slipper å spore av denne tråden mer enn nødvendig.

[Fjodorgrim]

Det heter ikke "skjører" det heter KJØRER !!

[Crowly]

Problemet er egentlig tatt fra en gammel bok angående operativsystemdesign og synkronsiering. Såvidt jeg vet har den ingen praktisk god løsning men om du er interessert i å fortsette denne debatten foreslår jeg vi gjør det over PM slik at vi slipper å spore av denne tråden mer enn nødvendig.

Etter hva jeg kan huske når jeg har gjort litt for mange ting på en gang, og dermed åpnet samme fil flere ganger, og lagret endringer i en av editorene. Så har jeg fått en melding i den andre editoren om at filen på disk nå har ett annet innhold enn det som er her, og om vil jeg hente inn det nye innholdet fra disk. Er vel det del_diablo nevner her "*Du får en popup om dette, som spør om du vil relaste filen siden den ikke stemmer i forhold til de nye foranderingene".

Da blir man i det minste gjort oppmerksom på at innholdet er endret, og har muligheten til å håndtere det.

 

Eierskap av filer bør vel minske sannsynligheten for at en slik situasjon oppstår.

[BeFs]

Men hvis du da ikke velger å se det nye innholdet, men velger å overskrive filen med det gamle innholdet, vil jo ikke filen bli korrupt. Den vil bare ikke inneholde de nye endringene.

[fenderebest]

Som sagt om det er noen som har lyst til å fortsette diskusjonen kan det tas på PM med meg. Ikke i denne tråden.

[BeFs]

Godt forslag! På den måten slipper noen å tape ansikt slik at alle kan se det.

[fenderebest]

Det blir meningsløst å ha side etter side men off topic innhold i denne tråden. Da er det ryddigere å gjøre det over over PM. Den konklusjoenen du kom frem til er uansett ikke helt riktig.

 

Unansett om du virkelig er ute etter å diskutere dette sakelig burde det da spille ingen rolle om det gjøres over PM. Om du har aversjoner for dette virker det mere ut som du er ute etter å krangle.

Endret 2. juli 2009 av fenderebest

[BeFs]

Eyh! Nå synes jeg du angriper uten grunn.

 

Det er mulig at jeg brukte ny og gammel på feil måte. Jeg skulle vel heller ha skrevet "de andre endringene" eller "de forrige endringene" alt etter som man ser det.

 

 

For at ikke forumet skal overbelastes vil jeg fra nå av ikke ha kommentarer på mine innlegg her på forumet, fra nå av ber jeg om at alle kommentarer kommer til meg via flaskepost.

[del_diablo]

Den konklusjoenen du kom frem til er uansett ikke helt riktig.

 

Og da bør man spørre: "HVORFOR?!", enkelt og greit. Du oppgir ikke grunn her i såfall.

[RolloThomasi]

Fenderbender:

Jeg skulle tro at hvert åpne program har en egen kopi av filen i ram - de endrer ikke på samme datasettet.

Når så dette skal skrives til disk er det den siste lagringen som blir gjeldende. Dette er forsåvidt det samme som har blitt sagt flere ganger før, men tenkte at en ekstra omformulering ikke kunne skade.

 

Kan det hende at denne gamle boken din er svært, svært gammel? Tenker da på at den omhandler systemer med f.eks. veldig lite ram, og som derfor behandlet filoperasjoner annerledes enn det gjøres i dag?Fenderbender:

Jeg skulle tro at hvert åpne program har en egen kopi av filen i ram - de endrer ikke på samme datasettet.

Når så dette skal skrives til disk er det den siste lagringen som blir gjeldende. Dette er forsåvidt det samme som har blitt sagt flere ganger før, men tenkte at en ekstra omformulering ikke kunne skade.

 

Kan det hende at denne gamle boken din er svært, svært gammel? Tenker da på at den omhandler systemer med f.eks. veldig lite ram, og som derfor behandlet filoperasjoner annerledes enn det gjøres i dag? Kanskje før Protected Mode kom på banen eller noe sånt?

[MaHuJa]

Fenderbender:

Jeg skulle tro at hvert åpne program har en egen kopi av filen i ram - de endrer ikke på samme datasettet.

 

Når du snakker om editorer, fra vi til notepad til visual studio and beyond, så stemmer det.

 

 

I en del andre scenarioer stemmer det ikke. Spesielt databaser som holder på mange gigabyte data, er det å lese hele filen, gjøre en forandring, og skrive alt tilbake, rett og slett ikke praktisk.

 

Dette kan da gjøres på to måter.

 

A - open, seek, read, seek, write, close

Rett og slett, du leser del lille biten du skal ha, gjør forandringen i ram, og skriver dette tilbake.

Hvis noe annet skriver til samme område som du skriver til, hvor en av dere ikke har lest den oppdaterte versjonen, så mister du data ja.

 

Noe av problemet med Fender's poster er vel kanskje bruken av ordet korrupt - hvis en oppdatering overskrives helt (som de fleste tenker på, se bl.a. referanser til hvordan editorer fungerer) så er filen ikke korrupt, den bare mangler informasjon. Hvis det bare er en delvis overskrivning kan det bli en helt annen sak.

 

B - map to memory, read, write, unmap

Ideen er at når du forandrer en byte i minnet skal den skrives til disk (bufres vel uansett) - samt antakelig oppdateres hos alle andre som har samme området mappet. Og her har du samme problemet som med multithreading/shared memory.

 

 

I begge tilfeller er det mildt sagt upraktisk hvis forandringen krever flytting av senere data noen byte frem eller tilbake (i motsetning til fixed-width row databaser) - noe som gjenspeiler seg i at variabel-lengde felt ofte lagres separat. Dette er vel en god del av grunnen til at editorer foretrekker å laste hele greia uansett - at de ofte legger til eller fjerner tegn (annet enn ved slutten av fila) også, ikke bare forandrer dem.

 

 

Så problemstillingen er høyst levende den dag i dag.

Endret 8. juli 2009 av MaHuJa

[fenderebest]

Husk forøvirig at et OS typisk ikke allokerer hele filen inn i RAM. Det allokerer bare den dataen det har bruk for. Derfor kan OS'et gjøre filen korrupt når det bare skal skrive tilbake litt av dataen til disk, men ikke har noen informasjon om strukturen til den nye filen.

[del_diablo]

Med mindre programmet er godt skrevet.

[fenderebest]

Nå snakker jeg ikke om noe program. Jeg snakker om hvordan OS'et i seg selv skal håndtere det.

[del_diablo]

Ha tilgjengelig lock og det der, men ikke tving det til at systemet skal funke sånn. Finnes det egentlig noen bedre løsning?