[linux-l] ein biscchen offtopic: php Frage

[Steffen Dettmer]

* Rainer Flicker wrote on Tue, Nov 26, 2002 at 22:50 +0100:
> > Kennst Du Dich mit dem Kram aus (oder sonst jemand hier)? 

> Meinst Du das finden von Speicherlecks? 

Ja, scheinbar gibt es da rumliegende Referenzen, und ganz groß
dieses blöde ByteArray vom ConsoleHandler (der doch Console
handeln soll, und nicht in ein ewig lang werdenden ByteStream!).

> Gibt es da nicht garbage collectoren, die so etwas unterstützen
> (sgi gc, ...)?

Ich weiß es nicht. Ich hab nur den Tip mit OptimizeIt bekommen,
bloß es hilft mir nicht so wirklich weiter, und ich hab auch
eigentlich keine Lust, den ORB nach sowas zu durchsuchen. Ich
werde mal einen eigenen LogHandler schreiben, und gucken, ob's
dann besser wird. Aber warum erzeugt ein ConsoleHandler so viel
Datenmüll (ein Array (!) mit irgendwann Megabyteweise Outputs -
die natürlich auch in der Console kamen)?!

Dann kriege ich auch manchmal kurz vor oder genau bei der GC ein
OutOfMemory, und im fast selben Moment ist wieder bißchen was
frei (50%, 40MB im Test!), aber der Thread ist dann schon platt
(OOM fängt man ja nicht, und was soll ich da auch groß tun!). Muß
ich jetzt einen Thread laufen lassen, der schon vorher
System.gc() aufruft?! Kann das denn das Java nicht selbst? Warum
funktioniert es mit Testprogrammen ohne CORBA und Log immer ;)?

> Eine nicht-thread-safe Bibliothekfunktion kann man am einfachsten
> thread-safe machen, indem man ein mutex-lock einführt.

Dann muß ich zu Fuß jede Funktion durchgehen, und gucken, was die
verwendet. Ich hab größtenteils schon immer getter, aber sind
auch noch genug Stellen. Vielleicht auch einen "mutex lock
decorator" (Performance ist größtenteils egal, weil meistens
jeder Thread eh ne eigene Instanz hat, ich mich aber aus
Super-Dead-Lock gründen nicht "traue", ständig das gesammte
Objekt zu locken, weil hin und wieder mal ein Check-Thread ein
Member prüfen sollte). Also kein "Rezept" hierfür bekannt?

> Dann hat man natürlich das Problem, dass ein Thread, der eine
> Funktion aufruft, die ein anderer Thread schon aufgerufen hat,
> blockiert wird.

Ja, also nicht async-safe. Dann mache ich über all sowas wie

synchronized (this) {
}

Als Lockobjekt auf dem Stack (wegen Exceptions etc) in C++, ja?
Gibt's da Mutex-Libs für? Muß doch alles Standard-Kram sein?!

> Wie es bei OOP mit async-safe aussieht, weiss ich leider nicht,
> ich kenn es nur von C. 

Wie macht man es da? Dann hab ich einen Zeiger zu einer Struktur
mit Zeigern als Parameter; kann man sowas async-safe machen?
Irgendwie verstehe ich den Sinn von async-safe nicht. Entweder
arbeite ich auf Kopien (Parameter, Stackvariablen), dann bin ich
es immer (und auch thread-safe), oder ich verwende Sachen, die
ich Locken muß, und bin dann thread-safe, aber nie async-safe.
Was bringt der Begriff also?

> Aber da die meisten OO Programmiersprachen eh wieder die libc
> verwenden, setzt sich das Problem fort (denk ich doch).

Ja, muß man irgendwie kapseln, klar. Das wäre weniger mein
Problem; das Design der Libs ist größtenteils gut, daß ich mir
hier wenig Sorgen mache - außer, was die Anzahl der Klassen
betrifft... 

> Wenn man Referenzen auf Objekte einer auzurufenden Funktion
> übergibt, dürfte es Probleme geben mit async-safe, ebenso beim
> Zugriff auf Dateien, oder globale Variablen.

Geht es überhaupt irgendwie?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.