[issue3710] Reference leak in thread._local

Changes by Ray.Allen : -- nosy: +ysj.ray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue3710] Reference leak in thread._local

Antoine Pitrou added the comment: Ok, then let's continue in #1868. -- resolution: -> duplicate status: open -> closed superseder: -> threading.local doesn't free attrs when assigning thread exits ___ Python tracker

[issue3710] Reference leak in thread._local

Ben Cottrell added the comment: The latest patch over in #1868 is working fine for my company in production, and solves #3710 as well. I think the only thing left to do on that patch is to make it special case "__dict__". -- ___ Python tracker

[issue3710] Reference leak in thread._local

Antoine Pitrou added the comment: > 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. Indeed. Therefore, perhaps we could break the problem in

[issue3710] Reference leak in thread._local

Changes by Terry J. Reedy : -- versions: -Python 2.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue3710] Reference leak in thread._local

Changes by Terry J. Reedy : -- versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0 ___ Python tracker ___ ___ Python-bugs-list ma

[issue3710] Reference leak in thread._local

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: fyi - This bug and #1868 (http://bugs.python.org/issue1868) seem related. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3710] Reference leak in thread._local

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue3710] Reference leak in thread._local

Ben Cottrell <[EMAIL PROTECTED]> added the comment: 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 t

[issue3710] Reference leak in thread._local

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > But then if there is a context switch during the last Py_XDECREF, then > it could be the case that self->dict is not set properly on return from > _ldict(). Well, C code is effectively locked in a single thread until the GIL is released. It

[issue3710] Reference leak in thread._local

Ben Cottrell <[EMAIL PROTECTED]> added the comment: But then if there is a context switch during the last Py_XDECREF, then it could be the case that self->dict is not set properly on return from _ldict(). Functions like local_setattro() use _ldict() more for its side effect (setting self->dict)

[issue3710] Reference leak in thread._local

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Hmm, rather than the while loop in your proposal, the proper idiom would be: PyObject *olddict = self->dict; Py_INCREF(ldict); self->dict = ldict; Py_XDECREF(olddict); -

[issue3710] Reference leak in thread._local

New submission from Ben Cottrell <[EMAIL PROTECTED]>: This is a copy of a message I sent to the python-dev mailing list; it was suggested in a reply that I file a bug for this issue. I'm filing it against Python 2.5 because that's where I noticed it, but it doesn't look like this code has changed