[Pyrex] pyrex for parrots?
len-l at telus.net
len-l at telus.net
Wed May 25 18:51:06 CEST 2005
On 24 May 2005 at 20:10, Michal Wallace wrote:
> On Thu, 19 May 2005, Greg Ewing wrote:
>
[snip]
> > Even without Pyrex, I wouldn't feel confident that
> > complex builtin types such as dictionaries would work
> > correctly in a refcount-disabled environment, since
> > their implementation may be using other Python
> > objects internally.
>
>
> Why do you say dangerous? I really know nothing about
> garbage collection, so I could be completely wrong,
> but what's the worst that could happen? A memory leak?
> (Parrot has it's own garbage collection scheme)
>
>
For a garbage collector to recognize that an object is alive, that object must either
be directly or indirectly referenced by some special root object or internal pointer
that by definition is alive. Python extension modules, Pyrex modules included, do
not provide this anchoring (my term). It is unnecessary with reference counting.
Pyrex may reference a newly created python object with an ordinary local C pointer.
A garbage collector would know nothing about this references, so it would assume
the object is dead.
Now CPython does have a cyclic garbage collector running in the background to
remove reference cycles. But this garbage collector is clever enough to use the
reference counts to decide if objects are truly dead. Again, no anchoring.
To sum up, attempting to compile and use a Python extension module with
garbage collection only would lead to objects being prematurely garbage collected,
causing all kinds ot confusion.
Lenard Lindstrom
<len-l at telus.net>
More information about the Pyrex
mailing list