Browse Prior Art Database

Emulating Memory Mapped File Input/Output on OS/2

IP.com Disclosure Number: IPCOM000116040D
Original Publication Date: 1995-Jul-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 107K

Publishing Venue

IBM

Related People

Nusbickel, WL: AUTHOR

Abstract

Disclosed is a method for emulating the behavior of memory mapped file Input/Output (I/O) on OS/2*.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Emulating Memory Mapped File Input/Output on OS/2

      Disclosed is a method for emulating the behavior of memory
mapped file Input/Output (I/O) on OS/2*.

      With memory mapped file I/O, an entire file appears to be in
memory for an application to access and modify.  Actual I/O
operations to or from the storage device containing the file are
automatically done for the application by the service provider, which
is typically the file system of the operating system.  However, this
function is not conventionally supported by OS/2.

      Fig. 1 is a C++ listing using a prototype interface
to provide a class definition of the class MemMapFile.
MemMapFile::GetCurrentAddress, which is shown as an inline method, is
an access method that returns the beginning of the committed memory
region, representing where the data resides in the memory mapped file
I/O block.

      Fig. 2 is a flow chart showing the logic flow of the class
constructor, which is responsible for opening the input filename and
for allocating a block of memory to represent the entire file.  The
file, memory, and buffer size information are saved for use by other
methods.

      Fig. 3 is a flow chart showing the logic flow of the class
destructor, which is responsible for flushing any outstanding writes
to the file on the storage device, for closing the file, and for
freeing the memory.

      Fig. 4 is a flow chart showing the logic flow of the
MemMapFileSeek(offset) method.  If an application needs to modify
data in a file, it can use the Seek(offset) method to access the
data.  This method works much the same way as a seek of a file on a
storage device.  However, when this method returns to the
application, data from the file on the storage device is loaded into
the memory map at the sought offset for subsequent access by the
application.  Subsequent Seek(offset) calls, as well as the class
destructor, cause the changed file to be written back out to the
storage device. ...