Python 2.0
adjih at technologist.com
adjih at technologist.com
Wed Jun 9 18:10:20 EDT 1999
More information about the Python-list mailing list
Wed Jun 9 18:10:20 EDT 1999
- Previous message (by thread): Python 2.0
- Next message (by thread): Python 2.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): Python 2.0
- Next message (by thread): Python 2.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list