mmap, more questions .....

[Roger Oberholtzer]

On Thu, 2005-08-04 at 09:10 -0500, Ben Duncan wrote:
> Thanks Roger. To address a few issues:
> 
> Windows - No WAY. I guess I'll do a reverse Bill Gates's and declare SLAG
> will MOST definitely not be DESIGNED to run on a WINDOWS server (client
> program from WIndows to the *NIX server, yes).
> 
> On some off-lists suggestions about using MySql/Postgres/SQLite, I am fully
> aware of those databases and their capabilities. However, since the initial
> thrust here is to "replicate" Appgen in an Open Source Environment, a
> "multi value" data file manager is going to be the easiest for migration
> purposes. It will also give to the FOSS community a real PICK like database
> engine. Hence the effort to create from tdb a MV data engine.
> There is also the fact SLAG is just a bunch of UI into S-lang and any number
> of databases can be tied to SLAG. I am just wishing to avoid the crap from
> the end user of "My stepson's first cousin is a real ACCESS and PlayStation wizard
> so I had him tweak our SQL database and now YOUR programs don't work anymore"
> syndrome.
> 
> 
> Now on to MORE questions about mmap.
> 
> According to the docs I am reading, mmap allows files to be shared by a common
> mmap allocation to multiple processes, is this true?

Same as regular files. You open() the file the exact same way, with
read/write flags, allowing control over which processes can read/write.
The mmap() call then allows you to control sharing with the MAP_SHARED
flag.

> How does it handle if program A opens an mmaps file DATA, then program B opens
> file DATA, then program A terminates, does mmap of DATA stay active? When does
> it get released?

The map resources remains until the last app finishes. The underlying
file is still a regular disk file. It is just that is is accessed via
virtual memory rather than read/fread. So, after all programs finish,
the disk file is available when the progrm restarts. This can be a very
powerful and easy way to maintain state across invocations - as long as
the file contains all that is needed to determine state.

> IF I need to have a file HEADER (not A record/row) in memory, so certain
> parameters can be kept (exclusive usage lock semaphores,etc) as well as
> the "current record" I am working with, how can that be handled?

Same way you would handle it with a structure in memory. The file does
not need to only contain your records. Any more than any data structure
would need to. Just think of a mmap()ed file as a permanant data
structure that can survive program restarts. And that can be much bigger
than your physical memory.

> What happens and how do you handle the case where program A has
> record 1 called up and program B needs record 10000?

They are independent. The only concern is keeping programs in sync when
things change. But this is the same problem you would have with FILE
access. In fact, if you use the MAP_SHARED flag, when in process A you
access the parts changed in process B, you get the changes direct. As
long as you do not make copies of the file contents, you get the changes
direct upon access. No seek/read each time to ensure you are current.
You may still need record locking to make this safe.

> On a NOTE of good fortune. The Mississippi Department of Wildlife,Fisheries and
> parks, of whom have been running Appgen in their Distribution Center for the last
> past 10 years, have decided to renew my Support contract for a period
> thru next June despite the fact I am no longer an authorized Appgen VAR. This
> is with the understanding that SLAG and the necessary conversion / applications
> will be completed by that time .....So ... SLAG has it's first customer ...
> 
> 
> Roger Oberholtzer wrote:
> > On Wed, 2005-08-03 at 08:52 -0500, Ben Duncan wrote:
> > 
> 
> > 
> > So, go the mmap route. It is portable to any Unix/Linux and even
> > Windows. Not that the latter is any concern, I guess.
> > 
> >