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?
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
