移植SQLite到新的操作系统上

1.简介

对于大部分应用，都是使用混合代码文件，sqlite3.c和头文件sqlite3.h。sqlite3.c代码可以编译和运行在Unix，Windows，OS2或者Mac OS系统上而不需要做任何改变或者特殊的编译选项。大部分应用都能直接使用SQLite。

大部分应用使用SQLite的默认配置都可以执行。

然而，对于特殊应用需要替换SQLite接口来更好的适应于应用。SQLite为重新编译设计了方便的接口。编译时配置选择如下：

• 可以用另外实现mutex子系统
• 对于单线程应用完全不适用mutex
• 重新配置内存申请子系统来使用内存申请单元而不是使用标准库里面的malloc
• 重新设计文件系统的接口。也就是说，重写SQLite中所有的系统调用，使用完全不同的系统调用同磁盘交互
• 重写其他的操作系统接口例如得到Zulu或者系统时间

通常而言，SQLite需要对三处不同的子系统进行改变或者重写。mutex子系统用于在共享线程时线性使用SQLite资源。内存申请子系统用于SQLite结构体和数据库缓存。最后，虚拟文件系统（VFS）用于在SQLite和底层操作系统直接提供合适的接口和特定的文件系统。我们称这三个子系统为SQLite的接口子系统。

我们强调大部分应用可以使用SQLite接口子系统解决。我们鼓励开发人员使用默认实现。

 

2. 配置或者替换Mutex子系统

多线程环境中，SQLite使用mutex串行访问共享资源。mutex子系统仅仅当应用以多线程方式访问SQLite。对于单线程应用，或者SQLite仅仅被一个线程访问，mutex子系统可以被忽略如下：

-DSQLITE_THREADSAFE=0

Mutex很便宜但并不免费，使用如果mutex完全禁止的话系能将会更好。最终文件也会更小。

当将SQLite作为共享库使用时，应用可以使用sqlite3_threadsafe函数API测试mutex是否可用。

SQLite的mutex可以在运行时通过sqlite3_config函数接口来禁止。调用如下：

sqlite3_config(SQLITE_CONFIG_SIGLETHREAD);

在运行时禁用mutex不如在编译时禁用效率高，因为此时每当mutex被请求时都需要做一次检查。但运行时仍然有好处。

对于多线程应用关注如何管理线程，SQLite支持可选的运行时配置。如下：

sqlite3_config(SQLITE_CONFIG_MULTITHREAD);

sqlite3_config(SQLITE_CONFIG_MEMSTATUS, 0);

这两个配置既可以单独使用也可以一起使用。SQLITE_CONFIG_MULTITHERAD设置禁用mutex，串行访问数据库。使用此设置，多线程使用SQLite是免费的，但是必须保证没有两个线程同时访问数据库。

SQLITE_CONFIG_MEMSTATUS 设置追踪内存申请。

 

SQLite在Unix应用上需要递归mutex。大部分现代线程实现支持递归mutexs，但是不是所有的。对于不支持递归mutex的系统，只能使用单线程模式。如果还是不行，SQLite支持可选择的递归mutex。

-DSQLITE_HOMEGROWN_RECURSIVE_MUTEX=1

 

3. 配置或者替换内存申请子系统

默认的SQLite为对象和缓存申请的内存是由标准库实现的malloc和free函数实现的。

 

sqlite3_config(SQLITE_CONFIG_MALLOC, &my_malloc_implementation);

4. 增加新的虚拟文件系统

从3.5版本开始，SQLite支持虚拟文件系统VFS。

VFS可以在运行时增加，通过使用sqlite3_vfs_register接口实现。

默认的SQLite包含在Unix，Windows和OS2的VFS配置。

 

5. 将SQLite移植到新的操作系统上

为了将SQLite移植到新操作系统上，这个操作系统不是默认的，系统必须提供

• 互斥子系统（如果是多线程）
• 内存申请系统（假设没有标准库的malloc）
• VFS实现