nicht angemeldet
Re:
Statt Dich zu freuen, endlich volle Kontrolle zu haben.
Du siehst das falsch, denke ich!
Ja, (so) denkst Du.
Es ist keine Lösung, am OS vorbei zu entwickeln.
Dem stimme ich zu. flock() gibt es schlichtweg für MS nicht, also analysiere ich mal, dass wir eh von unix-artigen oder -unartigen Systemen reden.
Filelocking, egal ob advisory oder, wenn das OS es kann, besser mandatory, ist eben Sache der Zugriffsschicht. Alle Methoden, die da nicht unumgehbar eingebaut sind, taugen in einem heterogenen Mutliuser-Netzwerkbetrieb überhaupt nichts.
Es fällt mir auf die Schnelle kein Linux℠ ein, was default ohne V IPC daher käme.
Es muss sichergestellt sein, dass das OS dem Prozess auf die Finger klopft, wenn er etwas anfassen will, was ihn (momentan) nichts angeht. Deshalb ist die Auffassung, Windows wäre mit seinem mandatory Locking das antiqierte System und Unix wäre mit seinem advisory Locking viel fortschrittlicher, auch die falsche Auffassung. Mandatory ist die Weiterentwicklung :-)
Das einzige Problem dabei ist der Ressourcenfraß. Mandatory Locking bedarf eben einer File-Deskriptor-Table im Filesystem des OS, und einer zusätzlichen Kopie (von Auszugsdaten) für jeden Prozess, der damit arbeiten will. Das kostet eben Speicherplatz für jedes offene File, auch wenn im Moment gar nicht aktiv zugegriffen wird.
Du bist noch bei Prozessen. Multithreading kam aber bereits in der Vergangenheit. flock() arbeitet nur mit _Prozessen_. Was machst Du zukünftig, wenn sich (endlich) auch PHP der threads bedient?
Semaphoren sind auch bei Debian da, flock() nach dem, was ich hier von Dir lesen muss, arbeitet aber nicht.
Es ist keine Lösung, am OS vorbei zu entwickeln.
Aha.
Gruß aus Berlin!
eddi
suit