Re: [sqlite] Fwd: sqlite3_busy_timeout() on NetBSD
=?ISO-8859-1?Q?Tobias_Rundstr=F6m?= <[EMAIL PROTECTED]> wrote:
>
> Got this email from this a developer of XMMS2 Sounds a bit scary,
> anyone have seen this before?
>
> Begin forwarded message:
>
> > From: Alexander Botero-Lowry <[EMAIL PROTECTED]>
> > Date: måndag 3 jul 2006 16.13.29 GMT-04:00
> > To: [EMAIL PROTECTED]
> > Subject: Fw: sqlite3_busy_timeout() on NetBSD
> >
> >
> > I'm an xmms2 developer who does most of the work of getting xmms2
> > working on the various BSDs. I've currently run into a strange problem
> > with sqlite3_busy_timeout on NetBSD. It seems that it doesn't timeout
> > at all.
> >
> > !DSPAM:44a97a9f190355315134984!
> >
>
Thanks for the login, Alex.
To test the behavior of sqlite3_busy_timeout on NetBSD, I
used the simple program shown below. This program sets the
busy timeout to 60, then runs the SQL statement given in its
second argument.
To do the test, I first opened the test database using the
regular sqlite3 shell and executed "BEGIN EXCLUSIVE" there.
Like this:
$ sqlite3 t1.db
sqlite> BEGIN EXCLUSIVE;
Then in a separate terminal window, Ii typed:
./a.out t1.db 'SELECT * FROM t1'
The a.out program froze waiting on the lock to clear. In
the first window I typed: COMMIT. This caused the a.out
program running in the second window to immediately return
its results.
So I am unable to reproduce the problem you are having
with sqlite3_busy_timeout. It appears to be working correctly
to me.
Perhaps you can suggest an different test that will
reproduce the problem?
---
#include
#include
static int print_result(void *notUsed, int nArg, char **apArg, char **apCol){
int i;
for(i=0; i
Re: [sqlite] Fwd: sqlite3_busy_timeout() on NetBSD
=?ISO-8859-1?Q?Tobias_Rundstr=F6m?= <[EMAIL PROTECTED]> wrote: > > > > I've not had any problems with sqlite3_busy_timeout on Linux. > > And I do not have NetBSD handy for testing. Not sure what the > > problem might be. > > Hello, > > Anything we can do to help? Give you access to a NetBSD machine, put > in some debug somewhere? > An SSH login on a NetBSD machine someplace would be nice. Send login information to my private email. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] Fwd: sqlite3_busy_timeout() on NetBSD
I've not had any problems with sqlite3_busy_timeout on Linux. And I do not have NetBSD handy for testing. Not sure what the problem might be. Hello, Anything we can do to help? Give you access to a NetBSD machine, put in some debug somewhere? -- Tobias
Re: [sqlite] Fwd: sqlite3_busy_timeout() on NetBSD
=?ISO-8859-1?Q?Tobias_Rundstr=F6m?= <[EMAIL PROTECTED]> wrote:
> Hello List,
>
> Got this email from this a developer of XMMS2 Sounds a bit scary,
> anyone have seen this before?
>
> >
> > I'm an xmms2 developer who does most of the work of getting xmms2
> > working on the various BSDs. I've currently run into a strange problem
> > with sqlite3_busy_timeout on NetBSD. It seems that it doesn't timeout
> > at all. Though sqlite3_busy_timeout() is set to 6, when:
> >
> > sqlite3_exec (sql, "PRAGMA user_version",
> > xmms_sqlite_version_cb, , NULL)
> >
> > is called, we immediately get back SQLITE_BUSY instead of having it
> > wait for the lock to end. I was able to very very hackishly work
> > around
> > this problem with:
> >
> >if (sqlite3_exec (sql, "PRAGMA user_version",
> > xmms_sqlite_version_cb, , NULL)
> > == SQLITE_ BUSY) {
> > xmms_log_debug("busy...");
> > sleep(1);
> > sqlite3_exec(sql, "PRAGMA
> > user_version",
> > xmms_sqlite_version_cb, ,
> > NULL);
> > }
> >
> > Obviously this isn't a real solution, but it does solve the problem...
> >
> > Is there something wrong with sqlite3_bus_timeout on NetBSD?
> >
I've not had any problems with sqlite3_busy_timeout on Linux.
And I do not have NetBSD handy for testing. Not sure what the
problem might be.
--
D. Richard Hipp <[EMAIL PROTECTED]>
