Confusion with weakref, __del__ and threading

George Sakkis george.sakkis at gmail.com
Thu Jun 12 06:41:21 CEST 2008


On Jun 11, 8:37 pm, Rhamphoryncus <rha... at gmail.com> wrote:
> On Jun 11, 2:15 pm, George Sakkis <george.sak... at gmail.com> wrote:
>
>
>
> > On Jun 11, 2:01 pm, Rhamphoryncus <rha... at gmail.com> wrote:
>
> > > On Jun 11, 10:43 am, George Sakkis <george.sak... at gmail.com> wrote:
>
> > > > On Jun 11, 1:40 am, Rhamphoryncus <rha... at gmail.com> wrote:
> > > > > The trick here is that calling proxy.sleep(0.01) first gets a strong
> > > > > reference to the Mystery instance, then holds that strong reference
> > > > > until it returns.
>
> > > > Ah, that was the missing part; I thought that anything accessed
> > > > through a proxy didn't create a strong reference. The good thing is
> > > > that it seems you can get a proxy to a bounded method and then call it
> > > > without creating a strong reference to 'self':
>
> > > That's not right.  Of course a bound method has a strong reference to
> > > self, otherwise you'd never be able to call it.  There must be
> > > something else going on here.  Try using sys.setcheckinterval(1) to
> > > make threads switch more often.
>
> > I tried that and it still works; all objects die at the main thread.
> > Any other idea to break it ?
>
> Nothing comes to mind.
>
> However, none of this is guaranteed anyway, so you can't rely on it.
> __del__ might be called by any thread at any point (even when you're
> holding a lock, updating a datastructure.)

Ok, you scared me enough to cut the link to the thread altogether,
avoiding the cyclic reference and the weakref proxy. The original
intent for keeping a reference to the thread was to be able to join()
it later before some cleanup takes place. I have since found a less
spooky way to synchronize them but regardless, I'd be interested for
an explanation of what's really going on in the posted snippets.

George



More information about the Python-list mailing list