--- al_todo.txt 2002/10/18 11:18:24 1.1
+++ al_todo.txt 2002/10/18 13:53:28 1.2
@@ -18,16 +18,47 @@
would allow arbitrary memory chunks to be specified for an application
provided destruction callback exists.
+x mlelstv:
+ insertion of externally provided memory chunks is the
+ exception, not the rule. Previously it couldn't be malloc'ed
+ because it was almost impossible to free it later. The latest
+ change to the API provides the necessary destruction callback.
+
+ I don't see specific "memory types" yet. Currently memory can be
+ allocated and freed. If we support "memory types" we need
+ a specific "memory" library that abstracts from these types
+ beyond malloc() and free(). Things like cache-coherency or
+ atomic access come to my mind.
+
+ Memory scopes are implied by the specific operations:
+ user API: LOAN == al_attach_buffer (and COPY with al_*_bytes)
+ internally: GIFT == al_splice (and COPY)
+ Providing public GIFT semantic requires to expose the internal
+ memory allocator. That's why I use LOAN.
+
+ No ideas about "memory access" types yet. What is the use for
+ a "read-only" assembly line ?
+
o rse: al.pod, DESCRIPTION:
perhaps add the buzzwords "zero-copy" and "efficient" somewhere just
to make sure people recognize that OSSP al is not "just another
trivial buffer library" ;)
+
+x mlelstv:
+ it is "copy avoidance" but not "zero-copy".
o rse: al.pod, al_attach_buffer:
scope still does not say anything about the content, i.e., is it
allowed that the application still changes the content (as long as the
size does not change)?
+x mlelstv:
+ the buffer is loaned to the library. Previously you wouldn't know
+ when it is returnd (and thus available). Now a callback function
+ is used to hand the buffer back.
+ The same mechanism is used internally for buffers allocated by
+ the library.
+
o rse: recommended renamings:
public:
al_txalloc -> al_tx_create
@@ -42,11 +73,29 @@
split_chunk -> chunk_split
dispose_chunk -> chunk_dispose
+x mlelstv:
+ alloc/free vs create/destroy: al_tx_t is no object, thus
+ no constructor, just an allocator. And that's denoted in the
+ function name.
+
+ al_apply sounds neat, but then al_traverse* need some neat
+ names too.
+
+ private naming: I don't like the change. Current names
+ are english phrases. "new" (== verb) "buffer" (== subject).
+
o thl: sanity checks and return of AL_ERR_ARG
+x mlelstv:
+ ACK
+
o thl: Es fehlt eine al_configure() call mit dem man die al_memops_t
beeinflussen kann.
+x mlelstv:
+ memops sind bisher private, sind sie ausreichend fuer public API ?
+ Ich glaube nicht. Und "erweiterbare" APIs wuerde ich gerne vermeiden.
+
o thl: Beim splicen entstehen shared buffers und deren bisherige Behandlung
ist rudimentaer, sorgt aber bereits fuer merklich Overhead usecount
in al_buffer_t). Das transferieren von Teilen solcher shared buffer
@@ -60,6 +109,17 @@
Verhalten, wegen al_attach_buffer() muss extra ein freemem flag
mitgescheift werden. Aber es wird gemacht und
funktioniert und ich wuesste auch keinen besseren Weg.
+
+x mlelstv:
+ usecount is notwendig, wenn man zukuenftig aliasing (== copy-on-write)
+ unterstuetzen will.
+
+ Eine feinere Behandlung von shared buffers wuerde ich, gerade wegen
+ des Overheads, vermeiden wollen. Buffer-Sharing dient nicht dem
+ Sparen von Speicher sondern dem Verhindern von Kopieroperationen.
+
+ freemem ist nicht laenger ein Flag, sondern ein (optionaler) Callback.
+ Flexibler.
o thl: Es ist weder in der Doku noch im Code beruecksichtigt, dass
die Assembly List zwischen al_traverse() und al_txfree() nicht
@@ -68,9 +128,27 @@
wohl nicht. Es gehen aber die waehrend des traversals dazugekommenen
Daten dem al_traverse_next() durch die Lappen, da die Datenmenge beim
al_traverse() berechnet wird.
-
+
+x mlelstv:
+ Korrekt. Erster Ansatz ist ein al_traverse_end() mit dem man ein
+ Traversal abschliesst (oder temporaer abschliesst, damit die notwendige
+ Re-Initialisierung automatisch wieder vorgenommen werden kann).
+
o rse: the library is not threadsafe nor even reentrant because there
are two static variables: alc_freelist, alc_freecount.
+x mlelstv:
+ ACK
+
+ solution 1: keep per al_t freelists, simple, but doesn't allow
+ a shared freelist.
+ solution 2: add global context that can be hooked into thread libraries.
+ solution 3: defer problem to a grid allocator library
+
+ I suggest solution 3 :)
+
o rse: the list.h macros lack a common prefix.
+x mlelstv:
+ wenn schon dann XML namespaces.... >-)
+
|
