After I hit <send> it struck me like a bombshell that the journal has to be there for the next startup to perform its complete function so such a method would fail. A virtual memory based object would only provide transactional support, not crash recovery. Humble pie for breakfast!

OS designers could think about providing a capability of tagging a file as private and making it immune to interference from gratuitous activity.

Here is a snippet of Windows and Unix code to create an anonymous object. In this particular concept it is used in an interpreter to allocate memory as a more durable alternative to allocating heap area with a malloc.

  /*Create a new anonymous mapped virtual memory object.*/
#if IS_WIN32
  hnd = CreateFileMapping((HANDLE)0xffffffff, NULL,
                          PAGE_READWRITE, 0, newtvsize, NULL);
  newtvar = MapViewOfFile(hnd, FILE_MAP_WRITE, 0, 0, newtvsize);
  if (newtvar == NULL) {       /*Failed*/
    /*Fatal error.*/
    errormet = TRUE;
    spring_trap(PARITY, 'T', ' ', ctxp);
    return;
  }  /*if*/
#else
  newtvar = mmap(NULL, newtvsize, (PROT_READ | PROT_WRITE),
                 (MAP_PRIVATE | MAP_ANONYMOUS), -1, (off_t)0);
  if ((int)newtvar == -1) {
    /*Fatal error.*/
    errormet = TRUE;
    spring_trap(PARITY, 'T', ' ', ctxp);
    return;
  }  /*if*/
#endif

[EMAIL PROTECTED] wrote:
John Stanton <[EMAIL PROTECTED]> wrote:

A suggestion for the journal files would be to make them private anonymous mapped objects.


The main purpose of the journal is so that if the program
or OS crashes or there is a power failure, once the machine
reboots and some other process tries to read the database,
the other process can see the journal and roll it back.
Private anonymous mapped objects defeat that purpose, it
would seem.

On windows, TEMP tables are stored in c:\temp\etilqs_* files.
But on unix, TEMP tables are stored in private, nameless
files that are automatically deleted after a crash.  On unix,
this is accomplished by opening a file then immediately unlinking the file while it is still open. Such files disappear
from the filesystem but are still available for I/O.  I don't
think that sort of thing is possible on windows, unless these
"anonymous mapped objects" you speak of might serve the purpose. Where do I find out more about "anonymous mapped
objects" for windows?

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------



-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to