/ Forside / Teknologi / Udvikling / Perl / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Perl
#NavnPoint
bjarneA 141
poul_from 50
soccer 30
Nicknack 14
Tmpj 0
Låsning af filer
Fra : Peter Makholm


Dato : 10-06-02 14:53

Jeg har en fil hvori der skal slettes nogle få linjer og indholdet af
filen skal bruges til vidre behandling. Da der bliver skrevet til
filen fra en del forskellige processer vil jeg gerne låse filen.

Hvis det skal foregå 100% korrekt, hvordan gør man så?

Jeg har følgende stykke kode:

#!perl

use Fcntl qw(:flock :seek);

# Finder den rigtige fil...

my @fil;

open FH, '+<', $fil;
flock FH, LOCK_EX;
while (<FH>) {
push @fil, $_ unless /blablabla/;
}
seek FH, 0, SEEK_SET;
print FH @fil;
flock FH, LOCK_UN;
close FH;

# Mere behandling af dataene i @fil;

__END__


Men er der ikke en teoretisk chance for at der er nogen der begynder
at pille i filen mellem at det andet kald til flock slipper filen og
kaldet til close sørger for at flushe filhandlet?

Ignorere folk denne mikroskopiske risiko eller sætter folk $| til 1?
Eller er der slet ingen risiko da close selv fjerner låsen?

--
Peter Makholm | We constantly have to keep in mind why natural
peter@makholm.net | languages are good at what they're good at. And to
http://hacking.dk | never forget that Perl is a human language first,
| and a computer language second

 
 
Thorbjoern Ravn Ande~ (10-06-2002)
Kommentar
Fra : Thorbjoern Ravn Ande~


Dato : 10-06-02 15:01

Peter Makholm <peter@makholm.net> writes:

> Men er der ikke en teoretisk chance for at der er nogen der begynder
> at pille i filen mellem at det andet kald til flock slipper filen og
> kaldet til close sørger for at flushe filhandlet?
>
> Ignorere folk denne mikroskopiske risiko eller sætter folk $| til 1?
> Eller er der slet ingen risiko da close selv fjerner låsen?

Fillåsning er som standard på frivillig basis under Unix.

Læs "perldoc -f flock" og bliv klogere/tristere.
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

Adam Sjøgren (10-06-2002)
Kommentar
Fra : Adam Sjøgren


Dato : 10-06-02 15:02

On Mon, 10 Jun 2002 15:52:55 +0200, Peter Makholm wrote:

> Men er der ikke en teoretisk chance for at der er nogen der begynder
> at pille i filen mellem at det andet kald til flock slipper filen og
> kaldet til close sørger for at flushe filhandlet?

perldoc -f flock siger:

To avoid the possibility of miscoordination, Perl
now flushes FILEHANDLE before locking or unlocking
it.

> Ignorere folk denne mikroskopiske risiko eller sætter folk $| til 1?
> Eller er der slet ingen risiko da close selv fjerner låsen?

Jeg mener at huske at close selv fjerner låsen. Jeg kan dog ikke på
stående fod huske hvor jeg har det fra.


Mvh.

--
"And if you complain once more Adam Sjøgren
You'll meet an army of me" asjo@koldfront.dk

Peter Makholm (10-06-2002)
Kommentar
Fra : Peter Makholm


Dato : 10-06-02 15:05

spamtrap@koldfront.dk (Adam Sjøgren) writes:

> perldoc -f flock siger:
>
> To avoid the possibility of miscoordination, Perl
> now flushes FILEHANDLE before locking or unlocking
> it.

Hmmm, jeg mener ellers at jeg har travet denne side gennem *mange*
gange, men åbenbart ikke godt nok. Og i forbindelse med at fillåsning
er frivillig, så er det godt at jeg skriver al koden der skal tilgå
filen selv.


--
Peter Makholm | Have you ever felt trapped inside a Klein bottle?
peter@makholm.net |
http://hacking.dk |

Peter Makholm (11-06-2002)
Kommentar
Fra : Peter Makholm


Dato : 11-06-02 13:56

Peter Makholm <peter@makholm.net> writes:

> Jeg har en fil hvori der skal slettes nogle få linjer og indholdet af
> filen skal bruges til vidre behandling. Da der bliver skrevet til
> filen fra en del forskellige processer vil jeg gerne låse filen.

Yderligere spørgsmål:

Når nu flere processer venter på samme låste fil kan jeg så antage
noget om i hvilken rækkefølge de får adgang? Jeg kan ikke finde noget
i nogen dokumentation der tyder på hverken det ene eller det andet, så
måske er det bare udefineret hvilken rækkefølge ting sker.

--
Peter Makholm | I have something to say: It's better to burn in
peter@makholm.net | hell, than to fade away!
http://hacking.dk | -- Kurgan

Peter Makholm (14-06-2002)
Kommentar
Fra : Peter Makholm


Dato : 14-06-02 20:24

Peter Makholm <peter@makholm.net> writes:

> Når nu flere processer venter på samme låste fil kan jeg så antage
> noget om i hvilken rækkefølge de får adgang?

Når ingen andre vil, så svarer jeg selv:

Nej, man kan ikke antage noget om hvilken rækkefølge processerne får
adgang til filen. Under Linux står der i /usr/src/linux/fs/locks.c en
kommentar om at linux godt nok gør det i en bestemt rækkefølge, men at
det ikke står en noget dokumentation.

--
Peter Makholm | According to the hacker ethic, the meaning of life
peter@makholm.net | is not Friday, but it is not Sunday either
http://hacking.dk | -- Peeka Himanen

Jakob Schmidt (24-06-2002)
Kommentar
Fra : Jakob Schmidt


Dato : 24-06-02 09:58

Peter Makholm <peter@makholm.net> writes:

> Peter Makholm <peter@makholm.net> writes:
>
> > Når nu flere processer venter på samme låste fil kan jeg så antage
> > noget om i hvilken rækkefølge de får adgang?
>
> Når ingen andre vil, så svarer jeg selv:
>
> Nej, man kan ikke antage noget om hvilken rækkefølge processerne får
> adgang til filen.

Jeg er så glad for at kigge ind i dette hyggelige forum igen, at jeg lader
en kommentar falde her, selvom jeg tvivler på, at du finder den relevant eller
brugbar:

Jeg var selv ude i det der låsningshelvede med flere tusinde brugere for noget
tid siden, og jeg bestemte mig for at tage sagen i egne hænder så at sige
og gå direkte til semaforerne. Perl har jo sine egne buitins, som påkalder
de tilsvarende UNIX funktioner (semget, semop, semctl), men der findes
også nogle glimrende OO-interfaces. Jeg brugte IPC::Semaphore.

Det er selvfølgelig besværligt at gå i gang med, men til gengæld får du lov
til selv at bestemme præcis, hvordan det foregår.

--
Jakob

Søg
Reklame
Statistik
Spørgsmål : 177579
Tips : 31968
Nyheder : 719565
Indlæg : 6409073
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste