zwischen:

[quote=nepos,18.04.2006, 14:23]Wenn ich das aus der Doku zu flock richtig lese, muesste man das Ergebnis von flock in ner Schleife auswerten. Sprich, ich warte solange, bis mir das flock ein TRUE zurueckgibt und damit anzeigt, dass er erfolgreich das Lock erhalten hat.
Solange von flock ein FALSE kommt, muss die Anwendung weiter warten.
Oder sehe ich das nun falsch?[/quote]
nein, flock() ist schon so schlau, dass es selbst wartet, bis es den zuschlag
kriegt.
"If LOCK_NB is bitwise-or'ed with
LOCK_SH or LOCK_EX then "flock" will return immediately rather
than blocking waiting for the lock (check the return status to
see if you got it)."

[quote=master,18.04.2006, 14:32]zwischen:
[/quote]
falsch. zum hundertsten mal: was genau kann denn da passieren?
ich bearbeite die datei doch erst nach dem flock.
ich warte noch auf die demo. was ist daran so schwer, das zu demonstrieren?
ein sleep einbauen, und schon müsstest du deinen erwarteten effekt
bekommen.

aber vielleicht willst du ja auf einfach recht behalten. tausende von perl-
programmierern haben also perl-programme am laufen, die nicht
korrekt implementiert sind. wie gut, dass wir den master haben, der
uns aufklärt.

Ah ok, haette ich wohl noch genauer lesen sollen :cool:
Aber im Prinzip bestaetigst du meine Annahme und ich kann hier auch keine Race-Condition sehen...

@Master: Wo liegt das Problem, wenn Prozess 1 die Datei oeffnet, dann Prozess 2 selbiges tut und sich nun Prozess 1 mittels flock den exklusiven Zugriff sichert? Wenn nun Prozess 2 ebenfalls ein Lock anfordern will, wartet er automatisch, bis Prozess 1 das Lock wieder freigibt. Genau so soll es ja laufen, Multitasking hin oder her. Wenn das ganze mit 500 Prozessen passiert, warten halt 499 und einer kann die Datei bearbeiten. Sobald er dann den Unlock macht, kommt einer der 499 wartenden Prozesse zum Zug.\n\n

<!--EDIT|nepos|1145364504-->

Ja, aber den inhalt hast du bereits vor dem flock geladen.

---
Ich versuche mal eine Demo zu machen..

Open laedt doch erstmal gar nichts, der holt sich doch nur mal das Handle fuer die Datei. Da ist doch sonst noch nix passiert, was mit dem Lesen/Schreiben auf die Datei zu tun haette.

[quote=master,18.04.2006, 14:32]zwischen:
[/quote]
Das open() mit "+<" öffnet die Datei zum Lesen und Schreiben, ändert aber nichts an der Datei selber. Daher existiert in diesem Code auch keine Race Condition, im Gegensatz zum Öffnen mit ">", was eine vorhandene Datei zum Zeitpunkt des Öffnens löscht (womit ein konkurrierender Prozess zu diesem Zeitpunkt eine leere Datei vorfindet).

Den Nachteil des Aufrufs mit "+<" sollte man aber nicht verschweigen: Im Gegensatz zum Öffnen mit ">" wird keine Datei angelegt, wenn sie nicht existiert! Dafür braucht man dann doch ein sysopen(), wie es in perldoc -q "get locking" beschrieben wird.

@dubu

Quote

habe das +< übersehen... dachte er öffnet mit "<", dann wird sie leer angelegt, und im hintergrund leer gelesen..

[quote=master,18.04.2006, 15:09]

Quote

habe das +< übersehen... dachte er öffnet mit "<", dann wird sie leer angelegt, und im hintergrund leer gelesen..

[/quote]
wen zitierst du hier?
falls das ein fehler war und obige aussage von dir stammt: nein, mit "<"
wird eine datei zum lesen geöffnet. und was genau meinst du mit "leer
gelesen"?

Trotzallem sollte man "sysopen" nutzen...
Es ist einfach besser als ein simples open < > +< wie auch immer...

@pq:
Hier habe ich noch was gefunden:
Link zum thema

Zudem gabs hier im forum schon oft user die das Problem mit
open, flock usw. hatten. schau dich mal etwas um, dann siehst du, dass es nicht blos heisse luft ist.
Oder google mal...

ps. ich öffnete früher immer mit "<" daher bekam ich damals trotz flock race-conditions