On 03/01/2018 15:58, Lifepillar wrote:
On 03/01/2018 15:48, Richard Hipp wrote:
On 1/3/18, Lifepillar <[email protected]> wrote:
Consider an extension that has some shared state, say a global `context`
struct, whose value is used by a few user-defined SQL functions.
Besides, assume that there are other SQL functions that can act on the
global context.
The question is: how do I turn this into a thread-safe extension?
Should I use SQLite3 mutex functions to guarantee exclusive access to
shared state? Or should I define my own locks?
Either approach will work. Which is easiest for you?
If SQLite3 locks may be used in loadable extensions, it is fine with me.
Thanks for the quick feedback!
Just wondering: if I put the context data into a sqlite3_vtab instance,
do I still need to take care of thread synchronization myself?
What I am currently doing is this:
1. Shared context data is allocated dynamically during initialization;
2. A pointer to the allocated context is passed to each application
function and to sqlite3_create_module_v2().
3. In my xConnect() I store the pointer into an object derived from
sqlite3_vtab.
4. Application functions and xUpdate() freely read and write through
the pointer.
I can make application functions access the context only for reading,
if that matters.
Life.
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
