Falls Ihr mal das Problem habt, irgend eine Nenenläufigkeit zu untersuchen und dafür in EINEM (Opera)-Browser zwei Reiter offen habt, mit exakt der gleiche URL: das gibt Probleme.

Aufgabe:
Ich wollte eine Semaphore einrichten und testen. Dafür hatte ich zwei Tabs offen, mit edxakt der gleichen URL. Ich habe jeweils beide Fenster gleichzeitig zum neuladen angeweisen.

Problem:
In der Log-Datei erschien immer nur EIN Prozess. Nicht beide.

Ursache:
Wenn Opera exakt die gleiche URL 2 mal abruft, wird das Ergebnis scheinbar Opera-Intern einfach verteilt. Es wird also selbst bei 20 Offenen Fenstern, die alle gleichzeitig laden, nur eine Abfrage gestartet und das Ergebnis in allen Fenstern dargestellt. Lädt man die Fenster einzeln und nacheinander neu, wird pro Fenster eine Abfrage gestartet.

Lösung:
Die URL nicht gleich belassen. Ich habe einfach einen nutzlosen Parameter angefügt und dann funktionierte es.

Ich hab das Ganze unter dem Linux-Opera v9.21 festgestellt. Ob das auch andere Versionen betrifft, weiß ich nicht.

PS: um in Perl die einzelnen Apache-Abfragen unterscheiden zu können ist die Variable $$, die enthält die ProzessID, sehr nützlich.

Das Teil geht mir mit der Zeit ein wenig auf die Nerven, da ständig Konflikte auftreten, wo keine sein können. Ich benutze mein SVN-Repository derzeit komplett alleine. Wenn ich allerdings irgendwas am Dateisystem ändere, also neue Dateien erstelle oder alte weglösche, egal ob nur im Dateisystem oder ob ichs über Eclipse mache.

Ich muss danach erst en Update machen, da sonst Konflikte beim Updaten der Verzeichnisse auftreten. Dummerweise sagt einem die Fehlermeldung “Cant commit” nicht unbedingt was aus. Ich hab nru durch viel rumprobieren die Lösung mit dem Update gefunden.

Was ich persönlich auch noch doof finde, ist die Tatsache dass man:

• Dateien, die man verschoben oder umbenannt hat, in der Commit-Historie per Hand suchen muss. Weiss man nicht mehr, wie die Datei vorher hieß, hat man verloren, wenn man mehrere Dateien gleichzeitig comitted.
• Verzeichnisse immer einzeln committen muss, wem na sie verschiebt oder umbenennt. Ich habe zwei Verzeichnisse, die untereinander liegen, umbenennen wollen. Das geht aber nicht, bevor ich nicht die erste ßnderung comittet habe. Generell sind verschiebe und Umbenennaktionen in uncomitteten Verzeichnissen nicht mehr möglich. Bei größeren Codeumbauten, die man erst am Ende comitten will, stellt das ein echtes Problem dar

Ansonsten geht es fast. Bis auf die Tatsache, dass im “Synchronize-View” manchmal keine geänderten Dateien auftauchen, die aber da sein müssen. Ein klick auf “Conflicts Mode” und dann wieder auf “Incoming/Outgoing Mode” löst das Problem. Mann muss es aber meißtens jedes mal machen, wenn das Problem einmal aufgetreten ist. Es scheint aber sporadisch zu sein…

Der InternetExplorer hat ein Problem, wenn man ein DIV absolut positioniert. Die Breite wird nur anhand des Inhaltes bestimmt, womit z.B. ein width: 100% nicht möglich ist. Er reagiert nur auf Pixelangaben. Grrr!

Der FireFox reagiert ebenfalls merkwürdig. Wenn man width: 100% verwendet, wird die Breite des Bildschirmes verwendet. Wenn man aber padding oder Margin verwendet, bleibt die Breite und das Element wird bei einem linken Margin oder Padding einfach nach rechts aus dem Bild verschoben. Ggf wird ein Scrollbalken eingeblendet. Hier hilft width: auto

Mal auf die Schnelle 2 Beispiele, wie man Methoden und Objektvariablen definiert:

myscript=new Object();
myscript.current=1;
myscript.init=function(){
// some code
}
myscript.validate=function(){
// some code
}

myscript={
current:1,
init:function(){
// code
},
validate:function(){
// code
}
}

zum Originalbeitrag

Normalerweise werden in Sprachen wie Perl und Java Objekte nicht explizit zerstört, da sich der Garbagecollector drum kümmert. Das wiederum kann zu sehr schwer auffindbaren Speicherlöchern führen, die ein Script in Sekundenschnelle auf 500MB RAM-Verbrauch bringen. Meisst hängt es damit zusammen, dass man sich die Objekte aus einer Fabrik holt, dort Referenzen eingesetzt werden und das Objekt wird dann einfach weggeforfen. Die Fabrik hat keine Ahnung, ob das Objekt schon weggeworfen wurde oder nicht.

Hier könnte ein kleiner Zusatzaufwand auf Programmiererseite viel helfen: man holt sich ein Objekt aus der Fabrik und bringt es nach gebrauch wieder zurück. Im Kinderzimmer musste man ja schliesslich hinterher auch immer aufräumen

Vorteil der Sache: die Fabrik kann intern entscheiden, was mit dem Ding passieren soll. Ist es ein Objekt, was nicht gecacht werden soll weil es z.B. so selten benutzt wird, dass es keinen Sinn macht, dann kann das Objekt von der Fabrik explizit zerstört werden. Soll es gecacht werden, kann es beibehalten werden und wird beim nächsten mal wieder ausgeliefert.

Beachten muss man bei dem Verfahren allerdings, dass man im Grunde 2 verschiedene Arten von Objekten braucht. Oder besser: 2 Fabrikmethoden. Eine zum Erstellen von Objekten, die man eh nur lesen will, die können problemlos gecacht werden, und eine zum erstellen von Objekten, die man ändern will. Letzterer Fall kommt in der Regel wesentlich seltener vor und das Cachemanagement kann beim zurückgeben dieser Objekte für änderungen abprüfen. Ist tatsächlich was geändert worden, kanndie Fabrik den “nurLeseCache” des entsprechenden Objektes grillen und alle sind glücklich.

Für die Speicherlöcher bedeutet das, dass man, bei extremen Speicherverbrauch, einfach in den nurLeseCache schaut und den ggf. korrigiert. Um Kreisreferenzen etc. muss man sich natürlich immer kümmern und ein explizites “destroy” oder “finalize” bei Objektzerstörung sollte man sich auch angewöhnen, aber das ist eine andere Geschichte und soll ein andermal…