*** /dev/null Mon May 6 23:45:39 2024
--- - Mon May 6 23:46:58 2024
***************
*** 0 ****
--- 1,76 ----
+
+ o rse: memory chunk maintainance
+ A piece of memory usually has the following 4 attributes which fully
+ describe it:
+
+ memory location: <pointer,length,size,refcount>
+ memory type: STACK|HEAP|SHMEM|CUSTOM
+ memory scope: LOAN|GIFT|[COPY]
+ memory access: READ_ONLY|READ_WRITE
+
+ With the current al_chunk_t/al_buffer_t such a description is only
+ partly possible, although IMHO (after efficiency) this flexibility in
+ describing arbitrary memory chunks has to be #1 priority.
+
+ Currently only al_attach_buffer() allows insertion of externally
+ provided memory chunks. But these then have to be malloc(3)'ed and
+ are not allowed to be allocated differently. For this the CUSTOM type
+ would allow arbitrary memory chunks to be specified for an application
+ provided destruction callback exists.
+
+ 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" ;)
+
+ 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)?
+
+ o rse: recommended renamings:
+ public:
+ al_txalloc -> al_tx_create
+ al_txfree -> al_tx_destroy
+ al_traverse -> al_traverse_start
+ al_traverse_cb -> al_apply
+ private:
+ new_buffer -> buffer_new
+ dispose_buffer -> buffer_dispose
+ make_buffer -> buffer_make
+ new_chunk -> chunk_new
+ split_chunk -> chunk_split
+ dispose_chunk -> chunk_dispose
+
+ o thl: sanity checks and return of AL_ERR_ARG
+
+ o thl: Es fehlt eine al_configure() call mit dem man die al_memops_t
+ beeinflussen kann.
+
+ 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
+ von einer al in eine andere ist derzeit ein Limit der Library.
+ Ein versehentliches anhaengen von Daten in anscheinend freie
+ Bufferbereiche, die aber doch von anderen Chunks genutzt werden,
+ wird derzeit schlicht durch Totalverweigerung der Nutzung von
+ evtl. freien Bufferbereichen bei shared buffers verhindert, indem
+ AL_CHUNK_RESERVE() einfach immer "null Platz" fuer shared buffer
+ (usecount > 1) zurueckgibt. Aehnliches gilt fuer das gift/loan
+ 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.
+
+ o thl: Es ist weder in der Doku noch im Code beruecksichtigt, dass
+ die Assembly List zwischen al_traverse() und al_txfree() nicht
+ veraendert werden darf. Ist auch nicht ganz so einfach zu erklaeren,
+ denn veraendern heisst z.B. splicen. Appenden und prependen stoert
+ 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.
+
+ o rse: the library is not threadsafe nor even reentrant because there
+ are two static variables: alc_freelist, alc_freecount.
+
+ o rse: the list.h macros lack a common prefix.
+
|
