On Wed, 21 Jul 2010 11:42:00 -0400
Jesse Noller <jnoller@gmail.com> wrote:
> On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden <mail@timgolden.me.uk> wrote:
> [...snip...]
> > A messy discussion turned on the question of garbage collection of module
> > objects, and the order in which finalisers are called if at all, especially
> > when reference cycles exist. Marc Andre was proposing a __cleanup__ magic
> > function
> > for Python modules, which would enable the implementer to define the order
> > in which resources are released / closed down. This is quite a subtle area
> > and raised the issue of unfinalised objects in a reference cycle whose
> > memory has been freed out from under them but which still exist. Martin
> > described
> > the Java approach where finalisers are called once and then flagged so
> > they are not called again even if their object is resurrected. This sounded
> > like a useful approach for Python but would break code which expected to
> > be able to resurrect an object during its __del__ method... which is not
> > expected to account for much code.
> >
> > Guido pointed out that no-one can be expected to hold enough of the
> > complexities
> > of this area of Python's implementation in their head, and that an
> > implementation
> > of some sort would need to be written so that the corner-cases could emerge.
>
> FWIW; I'm currently dealing with a bug in this area w.r.t
> multiprocessing and threads and modules we have imported vanishing due
> to this issue. I'm interested in hearing more.

One common resolution is to not use a __del__ method, but instead a
weakref callback which will do the necessary cleanup of a certain set
of resources. This is of course not applicable in all situations.

That's an option. I just remember Tim bringing up something about that approach that didn't quite work as a complete replacement for __del__.
">

(original) (raw)



On Wed, Jul 21, 2010 at 16:58, Antoine Pitrou <solipsis@pitrou.net> wrote:

On Wed, 21 Jul 2010 11:42:00 -0400
Jesse Noller <jnoller@gmail.com> wrote:
> On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden <mail@timgolden.me.uk> wrote:
> \[...snip...\]
> > A messy discussion turned on the question of garbage collection of module
> > objects, and the order in which finalisers are called if at all, especially
> > when reference cycles exist. Marc Andre was proposing a \_\_cleanup\_\_ magic
> > function
> > for Python modules, which would enable the implementer to define the order
> > in which resources are released / closed down. This is quite a subtle area
> > and raised the issue of unfinalised objects in a reference cycle whose
> > memory has been freed out from under them but which still exist. Martin
> > described
> > the Java approach where finalisers are called once and then flagged so
> > they are not called again even if their object is resurrected. This sounded
> > like a useful approach for Python but would break code which expected to
> > be able to resurrect an object during its \_\_del\_\_ method... which is not
> > expected to account for much code.
> >
> > Guido pointed out that no-one can be expected to hold enough of the
> > complexities
> > of this area of Python's implementation in their head, and that an
> > implementation
> > of some sort would need to be written so that the corner-cases could emerge.
>
> FWIW; I'm currently dealing with a bug in this area w.r.t
> multiprocessing and threads and modules we have imported vanishing due
> to this issue. I'm interested in hearing more.

One common resolution is to not use a \_\_del\_\_ method, but instead a
weakref callback which will do the necessary cleanup of a certain set
of resources. This is of course not applicable in all situations.

That's an option. I just remember Tim bringing up something about that approach that didn't quite work as a complete replacement for \_\_del\_\_.

Basically the whole setting a module's globals to None was done before gc came into the language. Now that it's there it seems that it might work to simply let gc clean up the module itself. But this brings in the question of how to order calling finalizers. It seemed the room had no specific answer other than it might just have to be near random as figuring out a reasonable order is hard.