🚀 go-pugleaf

CHEETAH@IUS.gun.de (Sven Tegethoff) writes:

>ME> >Denn  echtes  Belegen  des  Speichers würde dazu führen, daß AvailMem() nur
>ME> >wenig   freien   Speicher   meldet.
>ME> Was sicher nicht stoert.

>Sämtliche Programme, die einen möglichst grossen Zusammenhängenden
>speicherblock benötigen, schauen in die Röhre,

Nein. Warum sollten sie ?

>weil man sich mit
>dem dynamischen Cache ganz wunderbar den Speicher zerfräst,

Das haengt einzig und allein von der Strategie des Caches ab.

>und
>der noch nichtmal freigegeben wird.

Warum sollte der nicht freigegeben werden ? Weil Du das nicht willst ?

>Woher soll z.B. Audiomaster wissen, wieviel Speicher ich brauche, bevor
>ich mit dem sampeln angefangen habe ?

Du sagst es ihm oder er macht eine Abschaetzung und versucht einfach den
Speicher anzufordern.

>Und wenn ich mit dem Sampeln anfange, woher soll Audiomaster im vorraus
>wissen, wie lang das Stück werden soll ?

Muss er nicht wissen.

>Zu dumm, daß dank dem Cache MEMF_LARGEST nur 100 Kilobytes von 8MB sind...

Warum sollte Audiomaster denn den groessten zusammenhaengenden Block anfordern ?
Ich weiss, dass der das tut, aber das ist halt eine dumme Strategie.

>Ganz davon abgesehen, daß ich jetzt auch mit dem AVAIL-Befehl nicht
>mehr vernünftig abfragen kann, wieviel Speicher eigentlich _wirklich_
>zur verfügung steht,

Das konntest Du nie.

>es sei denn ich schaue immer per Hand die aktuelle
>cache-grösse nach, und ziehe sie vom belegten speicher ab.

Ein "avail flush" wird wohl den gesamten Cache flushen.

>Styleguide-Preis verliehen bekommt, aber nen dynamischen Cache nur über
>nen low-memory-handler zu implementieren finde ich vom Benutzerstandpunkt
>aus einfach gnadenlos unkomfortabel.

Direkten Hardwarezugriff zu verhindern ist fuer C0d3r auch unkomfortabel,
aber micht stoert das nicht.

-- 
                                Michael van Elst

Internet: mlelstv@serpens.rhein.de
                                "A potential Snark may lurk in every tree."