Python 2.0

adjih at technologist.com adjih at technologist.com
Thu Jun 10 00:10:20 CEST 1999


In article <87n1yc4k2e.fsf at ev.netlab.co.jp>,
  Yukihiro Matsumoto <matz at netlab.co.jp> wrote:
>
> adjih at technologist.com writes:
>
> |  It is true that it shouldn't be hard to make a mark-sweep collector
> |that is working in practice on many platforms.
> |
> |  Pedantically I doubt that ANSI-C tells you the current stack top
> |address, or guarantees that the whole address space between the
current
> |stack pointer and this top stack address is stack space. But I agree
> |that actual C compilers wouldn't do something too stupid, we
> |shouldn't care about this :-)
>
> You don't have to know stack address to implement mark-sweep register,
> unless you want to make it conservative.  The mark-sweep GC can be
> written in ANSI-C portable.

But then this can break Python C modules, because references are held
from the C stack. Just the snippet code:
[...]
PyObject* myint=PyInt_FromLong(19991999);
[...]
would break with a mark-sweep GC ignoring the stack.
(almost all the C/Python code creating objects is in danger).

Of course, the solution is to call GC only at some places, but isn't
there an relation between the Python stack and the C stack ?

For instance if a module creates an object and then calls a function
(which can call "eval"), isn't the big interpreter switch entered
a second time ? Can one GC at all before the function/eval return ?

-- Cedric


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.




More information about the Python-list mailing list