[issue4273] cycle created by profile.run

New submission from darrenr <[EMAIL PROTECTED]>: The profile module creates a reference cycle. See attached session. -- components: Library (Lib) files: profile_cycle.txt messages: 75582 nosy: darrenr severity: normal status: open title: cycle created by profile.run type: resource

[issue4273] cycle created by profile.run

darrenr <[EMAIL PROTECTED]> added the comment: The profile module creates a reference cycle. See attached session. Note: cycle can be broken by deleting reference to 'dispatcher' on profile.Profile() instance. ___ Python tracker <[EMAI

[issue4273] cycle created by profile.run

darrenr <[EMAIL PROTECTED]> added the comment: Issue also occurs in 2.6. Note that it only shows up if gc is set to save all cycles. -- versions: +Python 2.6 Added file: http://bugs.python.org/file11961/profile_cycle_26.txt ___ Python tracker &

[issue4273] cycle created by profile.run

darrenr <[EMAIL PROTECTED]> added the comment: 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. ___

[issue4273] cycle created by profile.run

darrenr <[EMAIL PROTECTED]> added the comment: 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 alloc

[issue4273] cycle created by profile.run

darrenr added the comment: 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

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

New submission from darrenr : Python's garbage collector holds GIL during collection and doesn't provide any method of interruption or concurrency with other Python threads within a single Python VM. This can be a problem for realtime applications. The worst-case performance of t

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

Changes by darrenr : -- components: +Interpreter Core type: -> resource usage ___ Python tracker <http://bugs.python.org/issue4794> ___ ___ Python-bugs-lis

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr added the comment: A 'stop-the-world' garbage collector that periodically released the GIL could be run in a second thread, allowing the main thread to break in and do some processing. However the nature of a stop-the-world collector means that it probably would not easily

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr added the comment: OK cool, that's the development strategy we've already adopted. Is this limitation of Python's garbage collector in relation to real-time applications documented anywhere? ___ Python tracker <http://bugs.py

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr added the comment: I ask because in my opinion a three-second pause on a modern machine is significant for any program with any sort of interactivity--significant enough to warrant a warning in the documentation. Python is a great language and I think it deserves an incremental

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr added the comment: Regardless of the type of algorithm used by the garbage collector that currently exists in Python, its worst-case performance is undesirable. I have some interest in implementing a garbage collector for Python with improved performance characteristics but don't r