Chapter 15.  Programmer Notes

Table of Contents

Signal handling
Error returns to applications
Environment variables
Multithreaded applications
Berkeley DB handles
Name spaces
C Language Name Space
Filesystem Name Space
Memory-only or Flash configurations
Disk drive caches
Copying or moving databases
Compatibility with historic UNIX interfaces
Run-time configuration
Performance Event Monitoring
Using the DTrace Provider
Using SystemTap
Example Scripts
Performance Events Reference
Programmer notes FAQ

Signal handling

When applications using Berkeley DB receive signals, it is important that they exit gracefully, discarding any Berkeley DB locks that they may hold. This is normally done by setting a flag when a signal arrives and then checking for that flag periodically within the application. Because Berkeley DB is not re-entrant, the signal handler should not attempt to release locks and/or close the database handles itself. Re-entering Berkeley DB is not guaranteed to work correctly, and the results are undefined.

If an application exits holding a lock, the situation is no different than if the application crashed, and all applications participating in the database environment must be shut down, and then recovery must be performed. If this is not done, databases may be left in an inconsistent state, or locks the application held may cause unresolvable deadlocks inside the environment, causing applications to hang.

Berkeley DB restarts all system calls interrupted by signals, that is, any underlying system calls that return failure with errno set to EINTR will be restarted rather than failing.