[PEAK] Re: [TransWarp] releasing component subtrees

Phillip J. Eby pje at telecommunity.com
Tue Oct 21 15:45:14 EDT 2003

At 09:18 PM 10/21/03 +0300, alexander smishlajev wrote:
>Phillip J. Eby wrote, at 21.10.2003 18:45:
>>>our application from time to time is runnung tasks that should die after 
>>>doing their job.  but my colleague found that the dead tasks remain in 
>>>memory because of circular references between parent and child 
>>>components that are not detected by python gc.
>>Python doesn't do GC on objects that have __del__ methods.  If you get 
>>rid of the __del__ method in your example, the GC should run.
>thank you.  it appears that nobody of our python programmers knew that.
>>There's an easier way, at least for your example.  Declare your 'task1' 
>>and 'task2' bindings as 'noCache=True'.
>i am sorry, i cannot figure out how to use 'noCache'.  everything i try
>in this example ends up with the same result: 'task1' and 'task2' stop
>reporting their creation and run.

That sounds odd.  noCache should result in task1 and task2 being created, 
but then immediately discarded.  Oh, I know what the problem is, and it's 
almost explicitly documented in the current docstrings.  :(  When you use 
noCache=True, suggestParent is effectively False, so the binding.Make 
doesn't give the tasks parents, so they never do anything (because they 
don't get an assembly event.  Here's what you'd have to do:

task1 = binding.Make(lambda self: TestTask(self), noCache=True)

Then, referencing 'self.task1' should create the task, but not keep a 
reference to it.  (Of course, each subsequent reference to self.task1 will 
also create a *new* task.)

>>>below is a simple example.  it creates a task with two subtasks.  each 
>>>of these tasks terminates as soon as it is run.  no reference is kept to 
>>>the container task,
>>Not true; every component has a reference to its parent; that's how they 
>>find their parents.
>of course.  i meant that no reference is kept outside the subtree in
>question.  sorry for being imprecise.

No problem.  I just wanted to make sure that others were not confused; 
that's why I challenge such imprecisions when they come up, to make sure 
that nobody takes them as precise descriptions of how the system works.

More information about the PEAK mailing list