Hi!
Christian Tismer wrote:
[EMAIL PROTECTED] wrote:
Author: cfbolz
Date: Thu Mar 16 15:02:22 2006
New Revision: 24466
Modified:
pypy/dist/pypy/rpython/memory/gctransform.py
pypy/dist/pypy/rpython/memory/test/test_gctransform.py
Log:
fix the quite broken gc_(un)protect code:
1)
* raise NotImplementedError in the base class, since (un)protect
does not
make sense for most gcs
2)
* make sure that the new operation introduced by
replace_gc_(un)protect has
the same result variable as the replaced operation. Otherwise we
will end
up with graphs that are missing a variable.
I agree that 2) is needed, although I don't understand it really,
'cause I thought the result of the operation would be never used.
Well, it fixed your example where the result _is_ used. And you never
know in what ways gc_(un)protect is used by somebody, so better safe
than sorry.
But I don't agree on 1). Maybe I need to learn more about
garbage collectors.
Are you saying that there exist GCs where I cannot protect an object?
It the operation is not necessary because the object will survive
anyway, then it is perfectly fine.
If you have a compacting GC, the protect operation makes very much
sense, too, but needs a different implementation of course.
After all, I agree that raising NotImplemented is right, because
itreally would need to be implemented. Still I can't see how
it "does not make sense for most GCs". It makes sense for those
which I know and use.
I think my wording could have been better. Indeed, most garbage
collectors can support that sort of "protection", at least if enough
effort is put into it. But for most GCs just removing the operation is
not the way to implement it. Therefore I raise NotImplementedError, to
remind the programmer to oberwrite the method. Because if he forgets it,
you can get a lot of very strange, unreproduceable results.
Cheers,
Carl Friedrich
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
