This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: cycle created by
Type: resource usage Stage:
Components: Library (Lib) Versions: Python 2.4, Python 2.6
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, darrenr, wplappert
Priority: normal Keywords:

Created on 2008-11-06 21:58 by darrenr, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
profile_cycle.txt darrenr, 2008-11-06 21:58 interactive session that shows profile cycle creation
profile_cycle_26.txt darrenr, 2008-11-07 18:35 interactive session that shows profile cycle creation in 2.6
Messages (11)
msg75582 - (view) Author: (darrenr) Date: 2008-11-06 21:58
The profile module creates a reference cycle. See attached session.
msg75583 - (view) Author: (darrenr) Date: 2008-11-06 22:04
The profile module creates a reference cycle. See attached session.

Note: cycle can be broken by deleting reference to 'dispatcher' on 
profile.Profile() instance.
msg75604 - (view) Author: Winfried Plappert (wplappert) Date: 2008-11-07 14:47
I tested profile_cycle.txt on both Python 2.5.2 and Python 2.6. The
cycle you are showing for release 2.4.1 cannot be seen on both releases.
Why dont't you try and upgrade to Python 2.6?
msg75608 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-11-07 17:53
Let's mark this as out of date then.
msg75609 - (view) Author: (darrenr) Date: 2008-11-07 18:35
Issue also occurs in 2.6. Note that it only shows up if gc is set to
save all cycles.
msg76802 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-12-02 23:16
Where is the problem, if these reference cycles are properly broken by 
the garbage collector *unless* you tell it not to?
msg76811 - (view) Author: (darrenr) Date: 2008-12-03 04:09
I work at a development house that has decided to tell gc to keep all
cycles, in order to prevent any cycles from being created at all. It's
analogous to the policy of keeping a C++ build warning-free.
msg76820 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-12-03 09:53
But the garbage collector was invented for this very purpose: to break
cycles! Take the following example which create a cycle for every
instance of the class (the profile module has similar code):

class C:
    def __init__(self):
        self.action = self.action_GO
        # cycle: the object's dict now contains a bound method 
        # which references the object
    def action_GO(self):

This kind of construct is useful, and probably the best one in some
cases. Would you ban it from your code? from the python standard library?

Reference cycles are not bad at all, as long as they only hold memory:
they will be reclaimed when the systems needs more memory. 

I agree that they can be a problem for other valuable resource: opened
files, sockets, database cursors... even one thousand of uncollected
sockets are not enough to trigger a collection.
For this usage, I suggest that you iterate over gc.garbage, only warn
for such objects and remove all others (and after, clear gc.garbage and
run gc.collect() without the debug flag)
msg76918 - (view) Author: (darrenr) Date: 2008-12-04 19:17
We've gotten into the habit of writing manual destructors to remove
references like the one you wrote. I think explicit destruction is a
useful paradigm when resource allocation is involved and it's important
to manage the allocation's lifetime closely.

However you've convinced me that it's OK to allow these types of
reference cycles, and to make an effort to clean up only cycles
involving instances with __del__ methods. I've been able to convince the
team. Thanks for helping to clear this up.
msg76930 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-12-04 21:48
Closing issue as "Not a bug".
(but we can continue the discussion here...)
msg77990 - (view) Author: (darrenr) Date: 2008-12-17 22:20
I think we still need to prevent collectable cycles in our Python code.
Here's the situation:

We've got a process that creates many Python objects, and it needs to be
responsive, it's not good for it to block on one operation for more than
100-200 ms. The automatic garbage collection is currently taking on the
order of 2 seconds for this process.

If we can guarantee that no collectable or non-collectable cycles are
being created, we can gradually increase the collection threshold, or
turn off the garbage collector entirely, reducing or eliminating the
blocking overhead of garbage collection.
Date User Action Args
2022-04-11 14:56:41adminsetgithub: 48523
2008-12-17 22:20:33darrenrsetmessages: + msg77990
2008-12-04 21:48:45amaury.forgeotdarcsetstatus: open -> closed
resolution: works for me
messages: + msg76930
2008-12-04 19:17:29darrenrsetmessages: + msg76918
2008-12-03 09:53:03amaury.forgeotdarcsetmessages: + msg76820
2008-12-03 04:09:02darrenrsetmessages: + msg76811
2008-12-02 23:16:40amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg76802
2008-11-07 18:39:57benjamin.petersonsetstatus: closed -> open
nosy: - benjamin.peterson
resolution: out of date -> (no value)
2008-11-07 18:35:29darrenrsetfiles: + profile_cycle_26.txt
messages: + msg75609
versions: + Python 2.6
2008-11-07 17:53:45benjamin.petersonsetstatus: open -> closed
resolution: out of date
messages: + msg75608
nosy: + benjamin.peterson
2008-11-07 14:47:03wplappertsetnosy: + wplappert
messages: + msg75604
2008-11-06 22:04:25darrenrsetmessages: + msg75583
2008-11-06 21:58:59darrenrcreate