Re: [pysqlite] Concurrency - first steps

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hugh Gibson wrote:
> Yes, we hit this. I've only recently discovered threading.local giving
> local thread storage which has simplified creating per-thread connections
> (previously had to create a connection in a global structure,
> necessitating a system-wide lock).

threading.local is a global struct.  It is just a dict with the keys
being the thread id.  No need for a lock since the thread id is unique.

> Do you mean if we use a common connection object, 

I meant if you were using the same connection object in multiple
threads.  To be able to do that with pysqlite you have to supply the
(undocumented) check_same_thread=False parameter to connect.

>  I ran the test in
> http://itsystementwicklung.de/pipermail/list-pysqlite/2008-September/00015
> 1.html without any problems.

That doesn't use the same connection across threads (pysqlite would have
complained).  An open connection is carried across a fork which SQLite
does not support (see other message on this list).  The good news is
that the subprocess module deliberately disables garbage collection
before the fork and keeps it disabled in the child process before doing
the exec so the SQLite connection is not used in any way.

>> I have fixed APSW for the next release but it also requires the next
>> version of SQLite to address various problems in SQLite.
> 
> Any pointers? 

It is all to do with the C api and error handling?  The gory details are
in the SQLite dev group but if you really want to know I can reiterate
them here.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkipKoACgkQmOOfHg372QRTLwCglfPhrH5frFt7nZE0OwDuljiC
VPcAn0U0yi/VyHX49URDvFDtRKJDwDxf
=PDdb
-----END PGP SIGNATURE-----