ossp-pkg/sio/al_todo.txt
1.1
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.
