#include <db.h>

int
memp_fopen(DB_ENV *env, char *file, u_int32_t flags,
    int mode, size_t pagesize, DB_MPOOL_FINFO *finfop,
    DB_MPOOLFILE **mpf);

Description

The memp_fopen function opens a file in the pool specified by the DB_ENV env, copying the DB_MPOOLFILE pointer representing it into the memory location referenced by mpf.

The file argument is the name of the file to be opened. If file is NULL, a private file is created that cannot be shared with any other process (although it may be shared with other threads).

The flags and mode arguments specify how files will be opened and/or created if they do not already exist.

The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more of the following values.

DB_CREATE

Create any underlying files, as necessary. If the files do not already exist and the DB_CREATE flag is not specified, the call will fail.

DB_NOMMAP

Always copy this file into the local cache instead of potentially mapping it into process memory (see the description of the DBENV->set_mp_mmapsize function for further information).

DB_RDONLY

Open any underlying files for reading only. Any attempt to write the file using the pool functions will fail, regardless of the actual permissions of the file.

On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by function memp_fopen are created with mode mode (as described in chmod(2)) and modified by the process' umask value at the time of creation (see umask(2)). The group ownership of created files is based on the system and directory defaults, and is not further specified by Berkeley DB. If mode is 0, files are created readable and writeable by both owner and group. On Windows systems, the mode argument is ignored.

The pagesize argument is the size, in bytes, of the unit of transfer between the application and the pool, although it is not necessarily the unit of transfer between the pool and the source file.

Files opened in the pool may be further configured based on the finfop argument to memp_fopen (which is a pointer to a structure of type DB_MPOOL_FINFO). No references to the finfop structure are maintained by Berkeley DB, so it may be discarded when the memp_fopen function returns. In order to ensure compatibility with future releases of Berkeley DB, all fields of the DB_MPOOL_FINFO structure that are not explicitly set should be initialized to 0 before the first time the structure is used. Do this by declaring the structure external or static, or by calling the C library routine bzero(3) or memset(3).

The fields of the DB_MPOOL_FINFO structure used by memp_fopen are described below. If finfop is NULL or any of its fields are set to their default value, defaults appropriate for the system are used.

int ftype;

The ftype field should be the same as a ftype argument previously specified to the memp_register function, unless no input or output processing of the file's pages are necessary, in which case it should be 0. (See the description of the memp_register function for more information.)

DBT *pgcookie;

The pgcookie field contains the byte string that is passed to the pgin and pgout functions for this file, if any. If no pgin or pgout functions are specified, the pgcookie field should be NULL. (See the description of the memp_register function for more information.)

u_int8_t *fileid;

The fileid field is a unique identifier for the file. If the fileid field is non-NULL, it must reference a DB_FILE_ID_LEN length array of bytes that will be used to uniquely identify the file.

The mpool functions must be able to uniquely identify files in order that multiple processes wanting to share a file will correctly identify it in the pool.

On most UNIX/POSIX systems, the fileid field will not need to be set and the mpool functions will simply use the file's device and inode numbers for this purpose. On Windows systems, the mpool functions use the values returned by GetFileInformationByHandle() by default -- these values are known to be constant between processes and over reboot in the case of NTFS (where they are the NTFS MFT indexes).

On other filesystems, (e.g., FAT or NFS) these default values are not necessarily unique between processes or across system reboots. Applications wanting to maintain a shared memory buffer pool between processes or across system reboots, where the pool contains pages from files stored on such filesystems, must specify a unique file identifier to the memp_fopen call and each process opening or registering the file must provide the same unique identifier.

This should not be necessary for most applications. Specifically, it is not necessary if the memory pool is not shared between processes and is re-instantiated after each system reboot, or the application is using the Berkeley DB access methods instead of calling the pool functions explicitly, or the files in the memory pool are stored on filesystems where the default values as described above are invariant between process and across system reboots.

int32_t lsn_offset;

The lsn_offset field is the zero-based byte offset in the page of the page's log sequence number (LSN), or -1 if no LSN offset is specified. (See the description of the memp_sync function for more information.)

u_int32_t clear_len;

The clear_len field is the number of initial bytes in a page that should be set to zero when the page is created as a result of the DB_MPOOL_CREATE or DB_MPOOL_NEW flags being specified to memp_fget. If finfop is NULL or clear_len is 0, the entire page is cleared.

The memp_fopen function returns a non-zero error value on failure and 0 on success.

Errors

The memp_fopen function may fail and return a non-zero error for the following conditions:

EINVAL

An invalid flag value or parameter was specified.

The file has already been entered into the pool, and the pagesize value is not the same as when the file was entered into the pool, or the length of the file is not zero or a multiple of the pagesize.

The DB_RDONLY flag was specified for an in-memory pool.

ENOMEM

The maximum number of open files has been reached.

The memp_fopen function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. If a catastrophic error has occurred, the memp_fopen function may fail and return DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail in the same way.

See Also