Заказные сборки SQLite
или
Перенос SQLite к новым операционным системам

1.0. Введение

Для большинства ситуаций рекомендуемый метод сборки SQLite это использовать кодовый файл объединения, sqlite3.c, и соответствующий заголовок sqlite3.h. Файл sqlite3.c должен собраться и работать на любом Unix и Windows без любых изменений или специальных параметров компилятора. Большинство приложений может просто включать sqlite3.c вместе с другими кодовыми файлами C, которые составляют приложение, собирать их всех вместе и получить рабочую и хорошо настроенную версию SQLite.

Большая часть работы приложений с SQLite пройдет нормально в конфигурации по умолчанию и без специальной конфигурации времени компиляции. Большинство разработчиков должно быть в состоянии полностью проигнорировать этот документ и просто построить SQLite из объединения без любых специальных знаний и не принимая специальных мер.

Однако, специализированные приложения могут хотеть или должны заменить некоторые взаимодействия встроенной системы SQLITE альтернативными внедрениями, более подходящими для потребностей применения. SQLite разработан, чтобы легко формироваться во время компиляции, чтобы удовлетворить определенные потребности отдельных проектов. Среди параметров конфигурации времени компиляции для SQLite:

• Замените встроенную mutex-подсистему альтернативным внедрением.

• Полностью отключите весь mutexing для использования в однопоточных приложениях.

• Повторно формируйте подсистему выделения памяти, чтобы использовать своего распределителя памяти вместо стандартного malloc().

• Перестройте подсистему выделения памяти так, чтобы она никогда не вызвала malloc() вообще, но вместо этого удовлетворила все запросы памяти, используя буфер памяти фиксированного размера, назначенный при запуске.

• Замените интерфейс к файловой системе с альтернативным дизайном. Другими словами, отвергните все системные вызовы, которые делает SQLite, чтобы общаться с диском, совершенно другим набором системных вызовов.

• Отвергните другие интерфейсы операционной системы, такие как требования получить всемирное или местное время.

Вообще говоря, есть три отдельных подсистемы в SQLite, которые могут быть изменены или отвергнуты во время компиляции. mutex подсистема используется, чтобы преобразовать в последовательную форму доступ к ресурсам SQLite, которые разделяются среди потоков. Подсистема выделения памяти используется, чтобы ассигновать память, требуемую объектами SQLite и для кэша базы данных. Наконец, подсистема виртуальной файловой системы используется, чтобы обеспечить портативный интерфейс между SQLite и основной операционной системой и особенно файловой системой. Мы называем эти три подсистемы "интерфейсными" подсистемами SQLite.

Важно понимать, что большинство запросов хорошо удовлетворяются встроенными реализациями по умолчанию подсистем интерфейса SQLite. Разработчики поощряются использовать встроенные внедрения каждый раз, когда возможно, и собирать SQLite без любых специальных вариантов времени компиляции или параметров. Однако, некоторые узкоспециализированные ситуации могут извлечь выгоду из замены или изменения этих встроенных подсистем интерфейса SQLite. Или, если SQLite будет использоваться на операционной системе кроме Unix (Linux или Mac OS X), Windows (Win32 или WinCE) или OS/2, тогда ни одна из интерфейсных подсистем, которые встроены в SQLite, не будет работать, и применение должно будет обеспечить альтернативные внедрения, подходящие для целевой платформы.

2.0. Настройка или замена Mutex

В мультипоточной среде SQLite использует mutexes, чтобы преобразовать в последовательную форму доступ к совместно используемым ресурсам. Подсистема mutex требуется только для доступа к SQLite от многократных потоков. Для однопоточных приложений подсистема mutex может быть полностью отключена, повторно собрав со следующим выбором:

-DSQLITE_THREADSAFE=0

Mutexes дешевые, но они не свободны, таким образом, работа будет лучше, когда mutexes будут полностью отключены. Получающийся образ библиотеки также будет немного меньшим. Выведение из строя mutexes во время компиляции является рекомендуемой оптимизацией для приложений, где это имеет смысл.

Используя SQLite в качестве общей библиотеки, применение может проверить, были ли mutexes отключены, используя sqlite3_threadsafe() API. Приложения, которые связываются с SQLite во время выполнения и используют SQLite от многократных потоков, должны, вероятно, проверить этот API, чтобы удостовериться, что они случайно не стали связанными с версией библиотеки SQLite, у которой отключены mutexes. Однопоточные приложения будут, конечно, работать правильно независимо от того, формируется ли SQLite, чтобы быть ориентированным на многопотоковое исполнение, хотя они будут немного быстрее, используя версии SQLite с отключенным mutexes.

SQLite mutexes также могут быть отключены во время выполнения, используя sqlite3_config(). Чтобы полностью отключить весь mutexing, приложение может вызвать:

sqlite3_config(SQLITE_CONFIG_SINGLETHREAD);

Выведение из строя mutexes во время выполнения не столь эффективно, как выведение из строя их во время компиляции, так как SQLite все еще должен сделать тест логической переменной, чтобы видеть, позволены ли mutexes или отключены в каждом пункте, где mutex мог бы требоваться. Но есть все еще исполнительное преимущество для отключения mutexes во время выполнения.

Для многопоточных проектов, которые выверены относительно того, как они управляют потоками, SQLite поддерживает альтернативную конфигурацию во время выполнения, которая является половиной пути между не использованием любого mutexes и использованием всех. Это может быть установлено следующим образом:

sqlite3_config(SQLITE_CONFIG_MULTITHREAD);
sqlite3_config(SQLITE_CONFIG_MEMSTATUS, 0);

Есть два отдельных изменения конфигурации здесь, которые могут использоваться вместе или отдельно. SQLITE_CONFIG_MULTITHREAD отключает mutexes, которые преобразовывают в последовательную форму доступ к объектам соединения с базой данных и подготовленным запросам. С этим урегулированием применение свободно использовать SQLite от многократных потоков, но это должно удостовериться, что никакие два потока не пытаются получить доступ к тому же самому соединению с базой данных или каким-либо подготовленным запросам, связанным с тем же самым соединением с базой данных в то же время. Два потока могут использовать SQLite в то же время, но они должны использовать отдельные соединения с базой данных . Второй SQLITE_CONFIG_MEMSTATUS отключает механизм в SQLite, который отслеживает полный размер всех выдающихся запросов выделения памяти. Это опускает потребность в mutex каждого вызова sqlite3_malloc() и sqlite3_free(), что экономит огромное количество mutex-операций. Но последствие выведения из строя механизма статистики памяти в том, что sqlite3_memory_used(), sqlite3_memory_highwater() и sqlite3_soft_heap_limit64() прекращают работать.

SQLite применяет pthreads для своего mutex-внедрения на Unix, и SQLite требует рекурсивного mutex. Самые современные pthread внедрения поддерживают рекурсивный mutexes, но не все реально это делают. Для систем, которые не поддерживают рекурсивный mutexes, рекомендуется, чтобы приложения работали только в виде единственного дерева сообщений. Если это невозможно, SQLite обеспечивает альтернативное рекурсивное внедрение mutex, построенное поверх стандартного "быстрого" mutexes pthreads. Это альтернативное внедрение должно работать правильно, пока pthread_equal() атомный, и у процессора есть последовательный кэш данных. Альтернативное рекурсивное mutex-внедрение позволено следующим переключателем командной строки компилятора:

-DSQLITE_HOMEGROWN_RECURSIVE_MUTEX=1

Перенося SQLite к новой операционной системе, обычно необходимо полностью заменить встроенную mutex подсистему альтернативой, построенной вокруг mutex-примитивов новой операционной системы. Это достигается, собирая SQLite со следующим выбором:

-DSQLITE_MUTEX_APPDEF=1

Когда SQLite собран с выбором SQLITE_MUTEX_APPDEF=1, он полностью опускает внедрение своих функций mutex. Но библиотека SQLite все еще пытается вызвать эти функции в случае необходимости, таким образом, приложение должно самостоятельно осуществить mutex-функции и соединить их с SQLite.

3.0. Формирование или замена подсистемы выделения памяти

По умолчанию SQLite получает память, в которой он нуждается для объектов и кэша от malloc()/free() стандартной библиотеки. Есть также продолжающаяся работа с экспериментальными распределителями памяти, которые удовлетворяют все запросы памяти от единственного буфера постоянной памяти, выделенного SQLite при запуске. Дополнительная информация об этих экспериментальных распределителях памяти будет предоставлена в будущем пересмотре этого документа.

SQLite поддерживает способность приложения определить альтернативного распределителя памяти во время выполнения, заполняя экземпляр объекта sqlite3_mem_methods указателями на режимы альтернативного внедрения, регистрирующего новое альтернативное внедрение, используя sqlite3_config():

sqlite3_config(SQLITE_CONFIG_MALLOC, &my_malloc_implementation);

SQLite делает копию содержания объекта sqlite3_mem_methods, таким образом, объект может быть изменен после вызова sqlite3_config().

4.0. Добавление новых виртуальных файловых систем

Начиная с version 3.5.0 (2007-09-04), SQLite поддержал интерфейс, названный virtual file system или "VFS". Этот объект несколько неверно назван, так как это действительно интерфейс к основной операционной системе, а не только к файловой системе.

Одна из интересных особенностей интерфейса VFS то, что SQLite может поддержать многократные VFS в то же время. Каждое соединение с базой данных должно выбрать единственную VFS для своего использования, когда связь открыта, используя sqlite3_open_v2(). Но если процесс содержит многократные соединения с базой данных, каждое может выбрать различный VFS. VFS может быть добавлена во время выполнения, используя sqlite3_vfs_register().

Сборки по умолчанию SQLite для Unix, Windows и OS/2 включает подходящую VFS для целевой платформы. SQLite для других операционных систем не содержат VFS по умолчанию, но приложение может зарегистрировать одну или больше во время выполнения.

5.0. Перенос SQLite к новой операционной системе

Чтобы перенести SQLite к новой операционной системе, не поддержанной по умолчанию, приложение должно обеспечить:

• Работу mutex-подсистемы (но только если это многопоточно).
• Работу подсистемы распределения оперативной памяти.
• Работу реализации VFS.

Все эти вещи могут быть обеспечены в единственном вспомогательном кодовом файле C и затем связаны с файлом "sqlite3.c", чтобы произвести сборку SQLite для целевой операционной системы. В дополнение к альтернативе mutex, подсистемам выделения памяти и новой VFS, вспомогательный кодовый файл C должен содержать внедрения для следующих двух задач:

• sqlite3_os_init()
• sqlite3_os_end()

Файл "sqlite3.c" содержит реализации по умолчанию VFS, sqlite3_initialize() и sqlite3_shutdown(), которые подходят для Unix, Windows и OS/2. Чтобы препятствовать тому, чтобы один из этих компонентов по умолчанию был загружен, когда sqlite3.c собран, необходимо добавить следующий выбор времени компиляции:

-DSQLITE_OS_OTHER=1

Ядро SQLite вызовет sqlite3_initialize() рано. Вспомогательный кодовый файл C может содержать внедрение sqlite3_initialize(), которое регистрирует соответствующую VFS и также, возможно, инициализирует альтернативную mutex-систему (если mutexes требуются) или делает любую инициализацию подсистемы выделения памяти, которая требуется. Ядро SQLite никогда не вызывает sqlite3_shutdown(), но это часть официального API SQLite и иное не обеспечивается, когда собрано с -DSQLITE_OS_OTHER=1, таким образом, вспомогательный кодовый файл C должен, вероятно, обеспечить его для полноты.