Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Resolve circular reference

Reply
Thread Tools

Resolve circular reference

 
 
moerchendiser2k3
Guest
Posts: n/a
 
      01-07-2011
Hi,

I have a small problem with circular references. I embedded Python
into my app and I have two types which are flagged with
Py_TPFLAGS_BASETYPE so I can inherit Python types from these types.
Lets call my C types A and B.


Here is the dependency:

class Foo(A):
e=Bar()

class Bar(B):
def __init__(self, p):
self.p=p
i=Foo()
j=Bar(i)

Everything works fine, the problem starts when I start to make a
circular reference in Python. In my embedded app I have a reference to
instance A. When I decref this reference its still alive because the
instance j(Bar) makes this object still alive. Is there any chance to
force this? Because without A the instance A shouldnt be alive
anymore. Thanks for any hint!!

Bye
 
Reply With Quote
 
 
 
 
MRAB
Guest
Posts: n/a
 
      01-07-2011
On 07/01/2011 02:24, moerchendiser2k3 wrote:
> Hi,
>
> I have a small problem with circular references. I embedded Python
> into my app and I have two types which are flagged with
> Py_TPFLAGS_BASETYPE so I can inherit Python types from these types.
> Lets call my C types A and B.
>
>
> Here is the dependency:
>
> class Foo(A):
> e=Bar()
>
> class Bar(B):
> def __init__(self, p):
> self.p=p
> i=Foo()
> j=Bar(i)
>
> Everything works fine, the problem starts when I start to make a
> circular reference in Python. In my embedded app I have a reference to
> instance A. When I decref this reference its still alive because the
> instance j(Bar) makes this object still alive. Is there any chance to
> force this? Because without A the instance A shouldnt be alive
> anymore. Thanks for any hint!!
>

Force what?

j refers to i, i refers to Foo, Foo refers to A. Therefore A should be
alive.
 
Reply With Quote
 
 
 
 
moerchendiser2k3
Guest
Posts: n/a
 
      01-07-2011
> Force what?
>
> j refers to i, i refers to Foo, Foo refers to A. Therefore A should be
> alive.


Oh, sorry. Force the deletion of A.
 
Reply With Quote
 
moerchendiser2k3
Guest
Posts: n/a
 
      01-07-2011
> Force what?
> j refers to i, i refers to Foo, Foo refers to A. Therefore A should be
> alive.



Oh, sorry. Force the deletion of instance Foo(A) and Bar(B).
 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      01-07-2011
On Jan 7, 3:58*am, moerchendiser2k3 <googler.
(E-Mail Removed)> wrote:
> > Force what?
> > j refers to i, i refers to Foo, Foo refers to A. Therefore A should be
> > alive.

>
> Oh, sorry. Force the deletion of instance Foo(A) and Bar(B).


If you don't want j to keep i alive, you should look at weak
referencing. (Look at the documentation for the weakref module.
Also, this has nothing to do with A and B being C-defined types; this
exact same behavior would happen even with Python types.)


Carl Banks
 
Reply With Quote
 
moerchendiser2k3
Guest
Posts: n/a
 
      01-10-2011
so there is no chance without using weakrefs?
any ideas, tips, workarounds how I might handle this?

bye, moerchendiser2k3
 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      01-10-2011
On Jan 10, 12:21*am, moerchendiser2k3 <googler.
(E-Mail Removed)> wrote:
> so there is no chance without using weakrefs?
> any ideas, tips, workarounds how I might handle this?


No, sorry: as long as a reference to an object exists, the object is
never deleted. There is no way to get around this.

Python in general isn't designed to allow for exact control over the
destruction of objects. Even in CPython, which uses reference
counting, there are a bunch of situations where a reference might be
stored to an object that keeps it alive. (Unexpected locations where
a stray reference might exist: an unpickler object, the _ symbol in
the interactive shell.) Other implementations, like Jython and
IronPython, don't use reference counting and don't provide for any
particular time at all for an object to be destroyed.

The recommended way to ensure timely release of resources in Python is
to provide a method (such as close or finalize) to explicity release
the resource--the object then lives on in a zombie state. The with
statement can be used in many cases to avoid the need to call this
method explicitly. For example, if you were to run this code in
Python:

with open(filename) as f:
g = f
print g

It would print <closed file 'whatever' ...>. The object still exists
because there is a reference to it, but the file has been closed.


If you can tell us why it's so important that the object be destroyed
at that given time, even while a reference to it exists, maybe we can
give you better suggestions.


Carl Banks
 
Reply With Quote
 
moerchendiser2k3
Guest
Posts: n/a
 
      01-10-2011
> If you can tell us why it's so important that the object be destroyed
> at that given time, even while a reference to it exists, maybe we can
> give you better suggestions.


Thanks for your answer! In my case the types A and B (in my example
above)
are a dialog and a dialog widget. At a special time I have to close
and
destroy all dialogs but this does not happen because the widget keeps
the dialog alive. I have the reference to the dialog
but after I closed the dialogs I also would like to destroy them
because
they have to free some special ressources.

Thanks a lot!! Bye, moerchendiser2k3
 
Reply With Quote
 
Stefan Behnel
Guest
Posts: n/a
 
      01-10-2011
moerchendiser2k3, 10.01.2011 18:55:
>> If you can tell us why it's so important that the object be destroyed
>> at that given time, even while a reference to it exists, maybe we can
>> give you better suggestions.

>
> Thanks for your answer! In my case the types A and B (in my example
> above)
> are a dialog and a dialog widget. At a special time I have to close
> and
> destroy all dialogs but this does not happen because the widget keeps
> the dialog alive. I have the reference to the dialog
> but after I closed the dialogs I also would like to destroy them
> because they have to free some special ressources.


Objects within a reference cycle will eventually get cleaned up, just not
right away and not in a predictable order.

If you need immediate cleanup, you should destroy the reference cycle
yourself, e.g. by removing the widgets from the dialog when closing it.

Stefan

 
Reply With Quote
 
moerchendiser2k3
Guest
Posts: n/a
 
      01-10-2011
On Jan 10, 7:18*pm, Stefan Behnel <(E-Mail Removed)> wrote:
> moerchendiser2k3, 10.01.2011 18:55:
>
> >> If you can tell us why it's so important that the object be destroyed
> >> at that given time, even while a reference to it exists, maybe we can
> >> give you better suggestions.

>
> > Thanks for your answer! In my case the types A and B (in my example
> > above)
> > are a dialog and a dialog widget. At a special time I have to close
> > and
> > destroy all dialogs but this does not happen because the widget keeps
> > the dialog alive. I have the reference to the dialog
> > but after I closed the dialogs I also would like to destroy them
> > because they have to free some special ressources.

>
> Objects within a reference cycle will eventually get cleaned up, just not
> right away and not in a predictable order.
>
> If you need immediate cleanup, you should destroy the reference cycle
> yourself, e.g. by removing the widgets from the dialog when closing it.
>
> Stefan


The PyWidget type does not own the widget, it just points to it. I
have an
idea, would this fix the problem?

I destroy the internal dictionary of the dialog which points to other
PyObjects?
Then I would cut the dependency.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
src-resolve: Cannot resolve the name ... ivanet@gmail.com XML 1 03-23-2007 12:10 PM
Repost: Using EntityResolver to NOT resolve a PE Reference =?ISO-8859-1?Q?Ricardo_Palomares_Mart=EDnez?= Java 0 08-19-2006 10:27 AM
Semi-circular definitions (plus circular references) Kiuhnm C++ 16 01-03-2005 03:49 AM
How to resolve "undefined reference to..." problems? Steven T. Hatton C++ 3 06-05-2004 03:53 PM
DTD entity reference resolve Per XML 4 02-04-2004 07:43 PM



Advertisments