Deadlock and a rather weird stacktrace
Hi everyone,
I'm currently working on a multithreaded GUI system in Python 2.6. In this
system I use conditions to coordinate synchronization. However, one condition
suddenly locks, without any cause. As a last resort I have written a small
routine to dump all the stack traces.
def dumpAllStacks(self):
for threadId, stack in sys._current_frames().items():
print "Thread with Id: %s" % threadId
traceback.print_stack(stack)
When the system is dead-locked, I invoke this method. One stack-trace strikes
me as odd:
Thread with Id: 1568
File "c:\PYTHON26\lib\threading.py", line 497, in __bootstrap
self.__bootstrap_inner()
File "c:\PYTHON26\lib\threading.py", line 525, in __bootstrap_inner
self.run()
File "c:\PYTHON26\lib\threading.py", line 477, in run
self.__target(*self.__args, **self.__kwargs)
File "c:\PYTHON26\lib\site-packages\magnum\gui\autogui.py", line 2558, in
__sendDataLoop
self.__sendDataCondition.wait(1)
File "c:\PYTHON26\lib\threading.py", line 256, in wait
_sleep(delay)
File "c:\PYTHON26\lib\threading.py", line 497, in __bootstrap
self.__bootstrap_inner() <<= What?
File "c:\PYTHON26\lib\threading.py", line 525, in __bootstrap_inner
self.run()
File "c:\PYTHON26\lib\site-packages\magnum\subsys\__init__.py", line 2242, in
run
self.updateTask()
File "c:\PYTHON26\lib\site-packages\magnum\subsys\__init__.py", line 2214, in
updateTask
self.statusServerModule.updateTaskWithConnection(self.statusServerConnection)
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\modules.py", line
2450, in updateTaskWithConnection
self.updateDataWithConnection(connection, updateAll)
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\modules.py", line
2488, in updateDataWithConnection
self.updateVariableData(varDataDict, frozenset(varDataDict))
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\modules.py", line
796, in updateVariableData
self.cmdMgr.updateVariableData(self.moduleId, varDataDict, forceVarIdSet) #
after this varMgr makes deepcopy
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\managers.py", line
441, in updateVariableData
self.notifyUpdateReport(updatedData)
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\managers.py", line
493, in notifyUpdateReport
with self.updateReportCondition:
File "c:\PYTHON26\lib\threading.py", line 205, in __enter__
return self.__lock.__enter__()
File "c:\PYTHON26\lib\threading.py", line 121, in acquire
rc = self.__block.acquire(blocking)
Can someone tell me how the sleep of one thread can continue as the 'run' of
another? Is this normal? Thanks in advance!
Regards,
Vincent van Beveren
___
Ing. V. van Beveren
Software Engineer, FOM Rijnhuizen
T: +31 (0) 30-6096769
E: v.vanbeve...@rijnhuizen.nl
--
http://mail.python.org/mailman/listinfo/python-list
The untimely dimise of a weak-reference
Hi everyone,
I was working with weak references in Python, and noticed that it was
impossible to create a weak-reference of bound methods. Here is a little python
3.0 program to prove my point:
import weakref
print("Creating object...")
class A(object):
def b(self):
print("I am still here")
a = A()
def d(r):
print("Aaah! Weakref lost ref")
print("Creating weak reference")
r = weakref.ref(a.b, d)
print("Oh, wait, its already gone!")
print("Ref == None, cause of untimely demise: %s" % r())
print("Object is still alive: %s" % a)
print("Function is still exists: %s" % a.b)
print("See:")
a.b()
I also tried this in Python 2.5 and 2.6 (with minor modifications to the syntax
of course), and it yielded the exact same behavior. Why is this, and is there
anything I can do about it? I wish to reference these bound functions, but I do
not want to keep them in memory once the object they belong to is no longer
referenced.
Regards,
Vincent van Beveren
___
Ing. V. van Beveren
Software Engineer, FOM Rijnhuizen
E: v.vanbeve...@rijnhuizen.nl
--
http://mail.python.org/mailman/listinfo/python-list
RE: The untimely dimise of a weak-reference
Hi Peter,
I did not know the object did not keep track of its bound methods. What
advantage is there in creating a new bound method object each time its
referenced? It seems kind of expensive.
Regards,
Vincent
-Original Message-
From: Peter Otten [mailto:__pete...@web.de]
Sent: vrijdag 30 juli 2010 15:06
To: python-list@python.org
Subject: Re: The untimely dimise of a weak-reference
Vincent van Beveren wrote:
> Hi everyone,
>
> I was working with weak references in Python, and noticed that it was
> impossible to create a weak-reference of bound methods. Here is a little
> python 3.0 program to prove my point:
>
> import weakref
>
> print("Creating object...")
> class A(object):
>
> def b(self):
> print("I am still here")
>
> a = A()
>
> def d(r):
> print("Aaah! Weakref lost ref")
>
> print("Creating weak reference")
>
> r = weakref.ref(a.b, d)
The instance doesn't keep a reference of its bound method. Rather the bound
method keeps a reference of its instance. Every time you say
a.b
you get a different bound method. What do you think should keep it alive?
> print("Oh, wait, its already gone!")
> print("Ref == None, cause of untimely demise: %s" % r())
> print("Object is still alive: %s" % a)
> print("Function is still exists: %s" % a.b)
> print("See:")
> a.b()
>
> I also tried this in Python 2.5 and 2.6 (with minor modifications to the
> syntax of course), and it yielded the exact same behavior. Why is this,
> and is there anything I can do about it? I wish to reference these bound
> functions, but I do not want to keep them in memory once the object they
> belong to is no longer referenced.
I fear you have to manage the methods' lifetime explicitly.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
RE: The untimely dimise of a weak-reference
Hi Gregory, > You can create your own wrapper that keeps a weak reference to > the underlying object. Here's an example. > [...] Thanks for the code! Regards, Vincent -- http://mail.python.org/mailman/listinfo/python-list
RE: The untimely dimise of a weak-reference
Hi Christiaan, > Instances of a class have no means of storing the bound method object. > The or unbound bound method is a simple and small wrapper that keeps a > reference to the class, "self" and the function object. Python keeps a > pool of empty method objects in a free list. The creation of a new bound > method just takes a few pointer assignments and three INCREFs. Okay, that also explains the consistent memory assignment. Maybe I'll create a bound-method caching object, see how slow/fast it is in comparison, and see what ever other issues I run into. Regards, Vincent -Original Message- From: python-list-bounces+v.vanbeveren=rijnhuizen...@python.org [mailto:python-list-bounces+v.vanbeveren=rijnhuizen...@python.org] On Behalf Of Christian Heimes Sent: vrijdag 30 juli 2010 16:44 To: python-list@python.org Subject: Re: The untimely dimise of a weak-reference Am 30.07.2010 16:06, schrieb Vincent van Beveren: > I did not know the object did not keep track of its bound methods. What > advantage is there in creating a new bound method object each time its > referenced? It seems kind of expensive. Christian -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
