Re: [pysqlite] APSW not releasing global interpreter lock for call to sqlite3_prepare_v2

Roger Binns <[email protected]> Tue, 06 May 2008 10:59:41 -0700
Newsgroups gmane.comp.python.db.pysqlite.user
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ken Rimey wrote:
> It looks to me like the problem
> is that execute() doesn't release the global interpreter lock when
> it gets a statement cache miss and has to call sqlite3_prepare_v2().

Thanks for reporting this - I filed it as
http://code.google.com/p/apsw/issues/detail?id=15

> Each SELECT statement is executed using a
> new Connection, defeating the statement cache. 

You can also just add spaces on the end to get the same effect.

> If I bracket the call to sqlite_prepare_v2() in statementcache.c with
> Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS,
> the problem goes away.  That is not to claim that this is necessarily
> a complete and correct fix.

I agree with your diagnosis although the current svn code is more
complex for releasing/acquiring the GIL.  This is because objects can be
used across multiple threads so there is now code in there to detect
abuse of that (eg if you tried to execute() on the same cursor in two
different threads at the same time, or close the same db concurrently in
two threads).

I also just checked the pysqlite code, and it does release the GIL in
most places where prepare is called.

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

iD8DBQFIIJyNmOOfHg372QQRAkZ4AJ0bWCj0osFgiRcZdfPqwPl61+ogCQCeJysA
2fhHqgWBwHluiLVE9S7ubrk=
=58FY
-----END PGP SIGNATURE-----