Loadable extension with shared state

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Loadable extension with shared state

Lifepillar
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? Is there an idiomatic way
to deal with cases like this in SQLite3?

Thanks,
Life.

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Loadable extension with shared state

Richard Hipp-3
On 1/3/18, Lifepillar <[hidden email]> 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?

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Loadable extension with shared state

Lifepillar
On 03/01/2018 15:48, Richard Hipp wrote:

> On 1/3/18, Lifepillar <[hidden email]> 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!
Life.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Loadable extension with shared state

Lifepillar
On 03/01/2018 15:58, Lifepillar wrote:

> On 03/01/2018 15:48, Richard Hipp wrote:
>> On 1/3/18, Lifepillar <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Loadable extension with shared state

Simon Slavin-3
On 5 Jan 2018, at 12:12pm, Lifepillar <[hidden email]> wrote:

> I can make application functions access the context only for reading,
> if that matters.

Nope.  Reading vs. writing doesn’t matter.  You treat them both the same.

Nor does it matter whether you’re doing something trivial with sqlite3_vtab() or doing a multi-row UPDATE.

What does matter is whether all your threads are using the same SQLite3 connection and whether they’re all using the same statement handle.  I don’t think you’ve made this plain anywhere, or whether it can be changed if it would help things.

In terms of SQLITE3_THREADSAFE, I can’t improve on

<https://sqlite.org/threadsafe.html>

Read that, do the thing in section 3, and if you have questions about it, ask here.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users