Confusion with weakref, __del__ and threading
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.
More information about the Python-list