Berkeley DB Reference Guide: Building Berkeley DB for UNIX systems

QNX

1. To what versions of QNX has DB been ported?

   Berkeley DB has been ported to the QNX Neutrino technology which is commonly referred to as QNX RTP (Real-Time Platform). Berkeley DB has not been ported to earlier versions of QNX, such as QNX 4.25.

2. Are there any QNX filesystem issues?

   Berkeley DB generates temporary files for use in transactionally protected file system operations. Due to the filename length limit of 48 characters in the QNX filesystem, applications that are using transactions should specify a database name that is at most 43 characters.

3. What is the impact of QNX's use of shm_open(2) for shared memory regions?

   QNX requires the use of the POSIX shm_open(2) and shm_unlink(2) calls for shared memory regions that will later be mapped into memory using mmap(2). QNX's implementation of the shared memory functions requires that the name given must begin with a slash, and that no other slash may appear in the name.

   In order to comply with those requirements and allow relative pathnames to find the same environment, Berkeley DB uses only the last component of the home directory path and the name of the shared memory file, separated by a colon, as the name specified to the shared memory functions. For example, if an application specifies a home directory of /home/db/DB_DIR, Berkeley DB will use /DB_DIR:__db.001 as the name for the shared memory area argument to shm_open(2).

   The impact of this decision is that the last component of all environment home directory pathnames on QNX must be unique with respect to each other. Additionally, Berkeley DB requires that environments use home directories for QNX in order to generate a reasonable entry in the shared memory area.

4. What are the implications of QNX's requirement to use shm_open(2) in order to use mmap(2)?

   QNX requires that files mapped with mmap(2) be opened using shm_open(2). There are other places in addition to the environment shared memory regions, where Berkeley DB tries to memory map files if it can.

   The memory pool subsystem normally attempts to use mmap(2) even when using private memory, as indicated by the DB_PRIVATE flag to DB_ENV->open. In the case of QNX, if an application is using private memory, Berkeley DB will not attempt to map the memory and will instead use the local cache.

5. What are the implications of QNX's mutex implementation using microkernel resources?

   On QNX, the primitives implementing mutexes consume system resources. Therefore, if an application unexpectedly fails, those resources could leak. Berkeley DB solves this problem by always allocating mutexes in the persistent shared memory regions. Then, if an application fails, running recovery or explicitly removing the database environment by calling the DB_ENV->remove method will allow Berkeley DB to release those previously held mutex resources. If an application specifies the DB_PRIVATE flag (choosing not to use persistent shared memory), and then fails, mutexes allocated in that private memory may leak their underlying system resources. Therefore, the DB_PRIVATE flag should be used with caution on QNX.

Copyright Sleepycat Software