On 01/29/10 02:17 PM, [email protected] wrote:
On Fri, Jan 29, 2010 at 01:09:23PM -0600, Shawn Walker wrote:
On 01/29/10 12:45 PM, [email protected] wrote:
Joanie found a problem with my last incarnation of this fix. The result
was a deadlock. I've tried to avoid this by changing the way the locks
are acquired. In particular, the __del__ method checks to see if it
must acquire the lock, or already has it. This is a bit kludgey, but
it's a corner-case of a corner-case. I've also added a bunch of
asserts, updated the faux lock DummyLock, and switched the transport to
use NRLock, which will result in a traceback instead of a deadlock if
this problem ever happens again.
http://cr.opensolaris.org/~johansen/webrev-14240-3/
So the only thing that comes to mind is that with the _is_owned()
check in __del__, that means that the logic is assuming that the
same thread that created the object will also garbage collect it.
Is that safe to assume? (Asking; don't know.)
I'm not sure I understand this comment. This is _is_owned from threading.py:
def _is_owned(self):
return self.__owner is currentThread()
The code in __del__ is checking to see if it's the lock owner, and if it
isn't, then it's acquiring the lock. So, if the thread that's garbage
collecting the object isn't the same thread that's currently holding the
lock, it will try to acquire the lock and wait for it to be released.
Did I answer your question?
For some bizarre reason I had it in my head that the acquire would fail
because it was an NRLock, but that wouldn't be true since it was a
different thread. Nevermind :)
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
