Index: ossp-pkg/sio/al_todo.txt
RCS File: /v/ossp/cvs/ossp-pkg/sio/Attic/al_todo.txt,v
rcsdiff -q -kk '-r1.1' '-r1.2' -u '/v/ossp/cvs/ossp-pkg/sio/Attic/al_todo.txt,v' 2>/dev/null
--- 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.... >-)
+