mmap, file descriptors, STREAMS ?? WTF??

[Ben Duncan]

Ok, I have found what looks like would be a good starting point in my
creating a embedded database for my SLAG project. This is intended to be
a multi-user multi read/writable file manager with multi-value attribute
extensions.

It will be based upon tdb, which is the database manager SAMBA uses. It, in
turn, is based upon GDBM, but has several extensions such as multi user and
row locking.

As in SO much of SLAG, I am having to learn a bunch of new stuff and my nearing 50 year
old brain is about to explode.

It deals with mmap versus STREAMS (FILE *) versus "user buffering".
Here is what I can gather thus far:

Since this is going to be a FOSS Appgen replacement, I have studied as much as I can
on AppGen's headers and C API, to come up with how Appgen does it.
Appgen uses a key/data pair with 512 byte block and uses a "internal buffering"
mechanism. There are routines that deal with "virtual memory" file system and
row locking is handled by using a semaphore locking byte in the file itself.

Now looking at tdb, it uses "file descriptors", but establishes using mmap.
MMAP is used thru and thru on tdb.

Reading on linuxselfhelp about the Glibc file stuff, suggest that one uses STREAM's as
opposed to file descriptors. That this is more " efficient " then using file descriptors.

Other reading materials on "how to write a database" suggest using file descriptors
and do your own "buffering".

HELP!!! I am now confused. Is not "mmap" a way to do "user buffering" ? Is not , based
upon the above info, Appgen doing something along the lines of "mmap"? Is "user buffering"
even the same as "mmap"? is "STREAMS" more effective than mmap or "user buffering"?

As always, thanks ....

-- 
Ben Duncan   - VersAccounting Software LLC 336 Elton Road  Jackson MS, 39212
"Never attribute to malice, that which can be adequately explained by stupidity"
        - Hanlon's Razor