06. august 2013 - 09:36Der er
13 kommentarer og 1 løsning
Skader det at fjerne fflush(NULL) ?
Hej Eksperter
Jeg har nogle problemer med et program der er ustabilt men det er ikke i en speciel situation det sker, det virker tilfældigt. Nogle gange virker programmet, andre gange ikke. Vi er ved at få grå hår fordi NETS sætter spørgsmålstegn ved vores pilot test.
Vi kan dog se at programmet, når det sker, ikke udskriver selv om det ikke er selve problemet.
Programmet anvender CallBack funktioner.
Noget af programmet var allerede udviklet af andre som et eksempel, så noget af koden havde jeg ikke undersøgt nærmere.
Nu opdager jeg at der findes et par fflush(NULL) statements i nogle funktioner der foretager udskrift til fil.
På nettet kan jeg bare finde noget om at det påvirker input/output og er godt at anvende ved udvikling.
Hvad betyder dette præcist? Hvad er den fulde konsekvens?
If stream points to an output stream or an update stream in which the most recent operation was not input, fflush() causes any unwritten data for that stream to be written to the file, and the st_ctime and st_mtime fields of the underlying file are marked for update.
If stream is a null pointer, fflush() performs this flushing action on all streams for which the behaviour is defined above.
Jeg har prøvet en del. Men det sure er at vi ikke længere kan fremprovokere fejlen på vores egen terminal (uden at fflush(NULL) var fjernet.
Men kunden oplever det stadig.
Det eneste vi har gjort er at flytte dankortterminalen fra /dev/ttyS2 til /dev/ttyS1. Det gjorde at den fik IRQ 3 og ligger med større rettighed end det meste andet.
Ja - Og så udskriver vi nu et par enkelte statusmeddelelser til en fil ved programstart før dankortterminalen sender nogle og dermed bliver filen oprettet tidligere.
Hvis en fil er i fopen mode, evt. under oprettelse - Vil det så give programnedbrud hvis andre programmer også åbner filen for at læse i den, prøver at slette den el. skrive til den?
Nej - det gjorde ingen forskel. Det compileren skriver i terminalen er helt ens.
Det eneste jeg overhovedet kan komme i tanke om er det med filerne.
Programmøren der læser/sletter filer er her bare ikke fordi han har ferie til mandag, så jeg kan ikke spørge ham hvornår i processen han gør det.
Nå - Så må jeg vente på ham.
Ville dette med at det andet program åbner og evt. slette filer få mit program til at crache el. evt gå i selvspind hvis det skete mens mit program var i fopen mode? Hvis det gør kunne det nemlig være årsagen til at det sker så uregelmæssigt.
Vi begynder virkelig at tro at det har noget med indlæsning af konfigurations filen at gøre fordi det andet program også bruger denne fil når den skal hente forskellige data om opsætning af terminalen.
Har du erfaring med den slags på Linux? Altså at 2 programmer åbner en fil samtidig.
Det kunne jeg selvfølgelig. Det er bare svært fordi vi dels ikke længere kan fremkalde problemet hos os selv, kun hos kunden, og desuden fordi problemet opstår så uregelmæssigt. Årsagen til den sidste del af mit spørgsmål var nemlig at hvis conf filen allerede ligger i cache skal mit program ikke hente den i ram'en og ville derfor nå indlæsningen inden det blev det andet programs 'tur' til at arbejde.
Hvis derimod der har været mange transaktioner uden kort vil conf filen være skubbet ud i rammen el. endda helt ud på disk. det vil da tage så lang tid at det vil blive det andet (JavaScript) programs 'tur' til at arbejde.
HVIS altså det med at flere læser på samme fil er et problem kunne det være forklaringen.
Det ville også forklare hvorfor andre programmører ikke oplever det samme ved deres udvikling (Kortterminalproducenterne står også helt på bar bund). De fleste udvikler til et Windows miljø (som jo ikke er flerbruger), og integrerer desuden deres program således at det ikke stopper mellem transaktionerne (á pro pos spm. 984110).
Nå - Jeg vil i indlæsningen tilføje et while loop på max. 3 og sleep(1) indbygget der samtidig tester om conf filen indlæses korrekt og ellers terminerer før transaktionen starter for alvor.
Hvis det lykkes så vil den mulighed for fejl være elimineret og hvis det lykkes vil NETS ikke klage over timeout i transaktioner.
Ok - Tak for al hjælpen. Jeg vil også prøve at læse mere om at sætte lock på filer/se om de lock'ede. MÅSKE sætter Mozilla lock på filer mens den arbejder med dem. Hvem ved.
Hmm mon din /dev/ttyS2 er sat forkert op i dit/kundens system? prøv at køre en dmesg og vis alle linier med /dev/ samt linien lige før og efter. De kommer muligvis 2-3 gange.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
