RetroSearch Browse

Mon Nov 17 15:11:24 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040287.html

"Tim Peters" <tim at zope.com> writes:

> Another scheme is to just run all the weakref callbacks associated with
> trash cycles, without tp_clear'ing anything first.  Then run gc again to
> figure out what's still trash, and repeat until no more weakref callbacks in
> trash cycles exist.  If the weakref implementation is changed to forbid
> creating a new weakref callback while a weakref callback is executing, that
> gc-loop must eventually terminate (after the first try even in most code
> that does manage to put weakref callbacks in trash cycles).

Maybe I'm misunderstanding, but in the presence of threads might that
not create much confusion?  I'm envisaging

1) object reaches refcount 0
2) weakred callback gets called
3) thread switch happens
4) new thread attempts to create a weakref callback, which fails
5) programmer goes insane

Or am I missing something?

Cheers,
mwh

-- 
  There's an aura of unholy black magic about CLISP.  It works, but
  I have no idea how it does it.  I suspect there's a goat involved
  somewhere.                     -- Johann Hibschman, comp.lang.scheme

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040287.html below:

[Python-Dev] Making weakref callbacks safe in cyclic gc