nicht angemeldet
Hallo ihr beiden,
Ein Posting vorher sah es fuer mich noch so aus,
wie wenn Du vorschlaegst, den Wert eines Pointers
(auf int gecastet) zur Bildung eines system-
global eindeutigen Dateinamens heranzuziehen.
Das geht natürlich nicht. Der wäre dann nur lokal
und nur at Runtime einmalig.
der Dateiname muß auch nur während der Laufzeit des
Programms eindeutig sein - das ist ja eine temporäre
Datei, die anschließend auf ihren endgültigen Namen
innerhalb des Cache umbenannt wird.
Wobei wir das Umbenennen als "hinreichend unteilbar"
angenommen haben - zumal es egal wäre, wenn ein zwei-
ter Prozeß das Ergebnis eines vorherigen überschreibt:
Bei der Komprimierung werden ja nicht semantisch ver-
schiedene Ergebnisse heraus kommen.
Insofern erfüllt die $PID semantisch betrachtet genau
das, was wir erreichen wollten ... es könnte jedoch
durchaus sein, daß ein absoluter (!) Adreßraumpointer
dieselben Eigenschaften könnte. Ein relativer (bei
einem Betriebssystem mit virtuellem Adreßraum) dagegen
würde wohl nicht reichen, denke ich.
Da er die URIs abbildet, also im Cache Verzeichnis
am Ende der Verzeichnisbaum abgebildet ist, sind die
Dateinamen eh eindeutig (sind ja erstens nur
statische Seiten und zweitens kann das durchaus bei
komplizierten Pfadumbauten seitens des Apachen auch
in die Hose gehen ;-).
Das habe ich jetzt nicht wirklich verstanden.
Der Cache-Baum repräsentiert _nicht_ den Dateibaum,
sondern den URI-Baum - es kann also bei entsprechenden
URL-Mappings durchaus vorkommen, daß dasselbe Dokument
mehrfach im Cache herumliegt. Das kommt m. E. aber
selten vor - seltener jedenfalls, als daß _überhaupt_
Mappings verwendet werden. Daß der URL-Raum auf
mehrere Datei-Teilbäume verteilt sein kann, damit
wollte ich fertig werden können.
Und ich wollte _eine_ Wurzel des Cache-Baums haben,
ohne dafür die Wurzel des gesamten Verzeichnisbaums zu
verwenden ... das wäre auch gegangen, hätte aber
längere Pfadnamen zur Folge gehabt.
Ist aber auch nichts halbes und nichts ganzes.
Würde den komprimierten String in Memory halten,
senden und dann erst in eine Datei schreiben.
Das verhindert auch Synchronisationsprobleme und
ist schnell.
Die Komprimierung wird (hoffentlich) so selten auf-
gerufen, daß dies (was wir durchaus auch in Erwägung
gezogen hatten) im Schnitt über alle Zugriffe kaum
eine Beschleunigung bringen würde.
Komprimieren im Hauptspeicher war bei meiner ersten
Perl-Implementierung (unter Verwendung von /bin/gzip)
gar nicht möglich und ist es auf meiner Domain (wo
kein Compress::Zlib installiert ist) auch jetzt noch
nicht. Zudem würde es mehr Speicher kosten, ohne
dafür eine nennenswerte Beschleunigung zu bewirken ...
Compress::Zlib würde eine in-memory-Komprimierung
bieten, aber ich sehe im Moment wenig Sinn darin.
Ich sehe auch nicht, wie das Komprimieren im RAM
Synchronisationsprobleme verhindern würde.
Irgendwann muß das Ergebnis der Komprimierung in
die Cache-Datei geschrieben werden - und dazu ist
entweder eine explizite Synchronisation notwendig,
falls gleich in die endgültige Datei geschrieben
werden soll (und nachfolgende lesende Cache-Zugriffe
müssen damit ebenfalls umgehen können) oder eben
die Trivial-Methode, nur fertige Dateien durch Umbe-
nennung um Cache "sichtbar" für andere Zugriffe zu
machen.
Globale, ja selbst nur lokale eindeutige Dateinamen
zu finden ist schwierig. Da sollte eigentlich
tmpfile() bzw tmpname() für einspringen.
In unserem Falle reicht es, $PID an den späteren
Namen der Cache-Datei anzuhängen. Im Cache gibt es
nur Dateien, die auf ".gz" enden, und solche tempo-
räre Dateien, die über ihre Endung unique sind.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael