Hi,
Just tried this beast (FYI: compiles and works in 7.6 as well), however there are some (minor) issues: - There is no query() method, which is inconvenient for simple statements like INSERT or DELETE - statement won't be executed with big_query() unless fetch_row() in result is called, which, in turn, makes code a bit ugly.
- When sleeping (in case of SQLITE_BUSY) - may be it makes sense to enable threads? Even 100 ms is quite a lot. Optionally, it might be useful to allow dynamic configuration of this interval. - Again when sleeping - there is no limit for sleeping, and (in theory) it could happen that we will sleep forever (buggy external lock or so). Regards, /Al
Well, you shouldn't use it directly. But I'll guess its done enough to expose it to the Sql module. (committing to cvs...)
On Wed, Nov 03, 2004 at 02:25:01AM +0100, Martin Nilsson (DivX Networks) @ Pike (-) developers forum wrote:
Well, you shouldn't use it directly. But I'll guess its done enough to expose it to the Sql module. (committing to cvs...)
But multi-threading stuff is still actual - some operations take looong time (vacuum, integrity_check), even some selects may take long time (depending on number of db users, locking, transactions, OS load etc).
Mutexes for every connection (sqlite3_open) are also necessary when threads are active ("It is never safe to use the same sqlite structure pointer simultaneously in two or more threads." - even when compiled with THREADSAFE).
I can do this, if you don't have time :)
Regards, /Al
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum