Lisp HUG Maillist Archive

FLI function (Sqlite) fails when called in display-callback

Hi Lispers,

I have a display-callback which calls some Sqlite functions via the FLI - specifically sqlite3_blob_open and sqlite3_blob_reopen, from the Sqlite incremental I/O API. I use the incremental I/O functions to open and iterate over blobs stored in the rows of an Sqlite database on disk. My wrapper for sqlite3_blob_reopen works fine when called from the Listener, but fails with an Sqlite I/O error when called from within an output-pane callback (this also happens for button callbacks). It will work, however, if I pass it to mp:process-run-function within the callback.

This suggests that there is some kind of threading issue occurring (though Sqlite is thread-safe). Perhaps it's something relating to the thread that the callback runs in - my assumption was that this would just be the same thread as the CAPI window, but perhaps that's not right.

This behaviour seems rather odd, and not the kind of thing I would expect to happen when interfacing with Sqlite, which is normally extremely robust. Before I head over to the Sqlite list I thought I'd try here, just in case anybody has an inkling of what the problem might be. I can follow up with some code if need be.

Regards,
Christopher

Re: FLI function (Sqlite) fails when called in display-callback

Christopher Melen wrote:
> I have a display-callback which calls some Sqlite functions via the
> FLI - specifically sqlite3_blob_open and sqlite3_blob_reopen, from
> the Sqlite incremental I/O API. I use the incremental I/O functions
> to open and iterate over blobs stored in the rows of an Sqlite
> database on disk. My wrapper for sqlite3_blob_reopen works fine when
> called from the Listener, but fails with an Sqlite I/O error when
> called from within an output-pane callback (this also happens for
> button callbacks).

What (extended) error codes are returned by sqlite?  Does it work from
inside the callbacks when you use open/close instead of reopen?

> It will work, however, if I pass it to mp:process-run-function
> within the callback.  This suggests that there is some kind of
> threading issue occurring (though Sqlite is thread-safe).

I assume you're not setting any threading-related options via
sqlite3_config. Did you confirm thread-safety by checking the return
value of sqlite3_threadsafe?

> Perhaps it's something relating to the thread that the callback runs
> in - my assumption was that this would just be the same thread as
> the CAPI window, but perhaps that's not right.

As far as I know, CAPI callbacks do indeed always run in the process
of the toplevel interface.

> This behaviour seems rather odd, and not the kind of thing I would
> expect to happen when interfacing with Sqlite, which is normally
> extremely robust. Before I head over to the Sqlite list I thought
> I'd try here, just in case anybody has an inkling of what the
> problem might be. I can follow up with some code if need be.

Wish I could offer some insight.  My own use of sqlite has been
largely problem-free, although I use a pool of dedicated workers to
handle database tasks, and a buffered-stream wrapper for blob I/O.

Even if the issue you're experiencing is resolved, I'd still suggest
using a separate process to interact with the database instead of from
directly inside UI callbacks (especially since you already said that
that works).


Mike


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Updated at: 2020-12-10 08:36 UTC