RE; mmap and EVEN MORE questions ...

[Roger Oberholtzer]

On Fri, 2005-08-05 at 13:37 -0500, Ben Duncan wrote:
> Ok, looking over tdb, it looks like it MAY not be what I want.
> 
> First, in accounting applications, a process may have the same file open
> multiple times (An A/R Aging report/screen is a prime example of this).
> What happens to the mmap if you need to have such a function?

Nothing. Unless both are changing things. Then you need a type of record
locking to maintain safe access. And things like intelligent record
deletion/insertion. If two processes share the data, it is easier if a
deleted record is only marked as such and that new records are appended,
not replacing deleted ones. Then, at some points, all processes need to
do garbage collection.

> 
> Tdb DOES not allow but a single instance process per process of a file open.
> It blocks multiple open attempts from the same PID.

If it is memory mapped, why have it open more than once? Do you have
regular memory open more than once? Nope. Just make a copy of the
pointer you get back from mmap. It is just a pointer - not a data
structure. This is the beauty of mmap. Accessing a part of the file not
in memory, via this pointer, causes a page fault, which tells the
virtual memory system to get that part of the file. Each access is
independent. So, if tdb does do mmap() access and does allow multiple
opens in different processes, maybe you are ok.

OOC, does tdb really make the mmap() aspect available? I would have
thought that all access was via some API and not direct on the
underlying storage.

> 
> Soo... I am looking at now GDBM with MY own extensions, removing ALL of the
> ndbm / dbm compatabilty and adding locking semaphores and a secondary
> file for B-Tree indexing.
> 
> Any Suggestions comments or other notes WOULD be greatly appreciated.
> 
> As always, thanks ...
> 
> 
>