LINUX.ORG.RU

Неблокирующий SQLite

 


0

2

Есть одно glib-приложение. Однопоточное. Все вызовы асинхронные. То, что выполняется долго возвращает результат по обратным вызовам. Нужно прикрутить к нему небольшую БД. Смотрю в сторону SQLite, который является почти стандартом для десктопных приложений - его тянут чуть ли не все браузеры и т.п. Так вот незадача - не могу найти у него неблокирующий API. Судя по всему, единственный вариант - это выносить работу с БД в отдельный поток, чего делать не хотелось бы. Нашёл некую поделку, которая, судя по описанию, даёт асинхронный API: http://code.google.com/p/sqlheavy/ Кто-нибудь оным пользовался?

Ну и, собственно, вопрос - как народ пользуется этим sqlite в однопоточных приложениях? Всякие там громоптицы/сабвёршны выносят работу с БД в отдельный поток или как?


Я вот не буду утверждать на все 100, но сикулайт, имея ОДИН файл для хранения одной «БД» не может быть не блокирующим, т.е. любое разовое изменение, какой-то апдейт, явно же должен лочить доступ к этому файлу. Так а в чем проблема то? даже если много и часто что-то меняется - вызов апдейта через обертку сикулайта не отпустит ранее чем сикулайт не отпустит свою блокирувку.

deep-purple ★★★★★
()

Да, Вам придётся выносить работу с БД в отдельный поток, если Вы хотите настоящей асинхронности. Но для простых запросов и в случае, если нет множественного доступа к БД, sqlite даёт достаточную производительность для того, чтобы попробовать работать с ней синхронно из одного потока.

Sorcerer ★★★★★
()
Ответ на: комментарий от sdio

Где это сказано?

http://www.sqlite.org/docs.html

«Asynchronous IO Mode This page describes the asynchronous IO extension developed alongside SQLite. Using asynchronous IO can cause SQLite to appear more responsive by delegating database writes to a background thread. NB: This extension is deprecated. WAL mode is recommended as a replacement.»

Кроме того, модуль давал лишь асинхронную запись.

xusrol
() автор топика
Ответ на: комментарий от deep-purple

Не, чтение блокируется (ожидает пока отпустит) только когда кто-то уже в данный момент что-то апдейтит.

Сами запросы могут быть достаточно долгими, если БД разрастётся.

xusrol
() автор топика
Ответ на: комментарий от xusrol

Блин, если это такая БД, что она будет пухнуть как на дрожжах, то сикулайт тут уже не проканает. Ну или проканает, но с такими вот тормозяшками. Посему - самое оно вынести это дело в отдельный поток, и пусть он там пыхтит обновляет то что нужно.

Кстати, а что делать если пользак что-то там жмакнул в гуе и мы тут в отдельном потоке что-то пыхтим, но не успели до конца, а пользак уже закрыл/остановил прилагу?

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

В нормальных API на такой случай есть Cancellable, который позволяет отменить асинхронную операцию. А в случае SQLite, полагаю, нужно ждать пока не закончится операция.

xusrol
() автор топика
Ответ на: комментарий от xusrol

Ну вот таки значит еще один путь - искать другой инструмент взамест сикулайта, т.к.: а) лочит все б) может зафейлится при закрытииприлаги в) объем базы будет расти

deep-purple ★★★★★
()
Ответ на: комментарий от xusrol

На этом же потоке крутится UI, не хотелось бы получать подвисоны при доступе к БД.

UI проще вынести в отдельный поток.

x3al ★★★★★
()
Ответ на: комментарий от x3al

UI проще вынести в отдельный поток.

Ты хотел сказать - логику вынести в отдельные потоки.

anonymous
()

А смысл? Там файловый io, а асинхронный файловый io в posix и в линукс делается через одно место, очевидно, в sqlite использовать такой API не стали. Если очень надо, то выноси в отдельный тред.

Reset ★★★★★
()

sqlite в конкурентной среде веселуха...

Пусть каждый процесс мутирует свои ресурсы, остальным - чтение.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.