This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tamino
Recipients pitrou, tamino
Date 2008-08-28.00:51:20
SpamBayes Score 5.358747e-06
Marked as misclassified No
Message-id <1219884681.31.0.719150129398.issue3710@psf.upfronthosting.co.za>
In-reply-to
Content
The specific thing that was happening for me is that an
_sqlite3.Connection object was in the dictionary. In
Modules/_sqlite/connection.c, in pysqlite_connection_dealloc(),
it uses Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS.

So it's the call to Py_DECREF that's interesting from my point
of view. I believe that if _ldict() sets self->dict to what it
should be for the current thread, and then calls Py_DECREF on
the old value, and then returns, then _ldict() is no longer
able to guarantee that self->dict will be set to the right
thing for the current thread after it returns (because if the
Py_DECREF ended up deallocating something like an sqlite3
connection, then it'd have released and reacquired the GIL).

Hence, in the patch I attached, the assignment into self->dict
is kept as the last thing that happens before _ldict() returns,
and I believe this means _ldict() can still make that guarantee.

Of course, I'd be all for changing local_getattro/local_setattro
to not need _ldict to make that guarantee! _ldict always *returns*
the correct pointer; it would be nice to make use of that somehow.
History
Date User Action Args
2008-08-28 00:51:21taminosetrecipients: + tamino, pitrou
2008-08-28 00:51:21taminosetmessageid: <1219884681.31.0.719150129398.issue3710@psf.upfronthosting.co.za>
2008-08-28 00:51:20taminolinkissue3710 messages
2008-08-28 00:51:20taminocreate