fork()

Christian Tismer tismer at appliedbiometrics.com
Tue Jun 8 21:17:52 CEST 1999


Vladimir Marangozov wrote:
> 
> Graham Matthews wrote:
> >
> > Tim Peters (tim_one at email.msn.com) wrote:
<snip/>

> Graham, you said that you won't contribute a RC+GC scheme to Python, despite
> your positive experience. If you change your mind and consider
> devoting some spare time to give it a try, I'll devote some spare
> time to help you with Python's internals and we'll see whether we
> could come up with something viable, which could compete with the
> actual RC scheme alone. Does this sound constructive enough? :-)

Just an idea here:
If we have knowlegde of the internals of every Python structure,
and if there were no hidden internal references to Python
objects, then we could quite easily build a non-pessimistic
GC, without the need to be hardware specific, scan the stack
and so on.
You know that I have an (early) Python with no stack.
Would this help?

Let's assume that we use our own allocator. Something which
allows to create a couple of heaps which can be identified.
Now, with every new interpreter incarnation, a new heap
could be associated.
Under the assumptions that
- only known types are garbage collected
- only known (well-behaved) functions are called,
it seems to be safe to me to run a garbage collector
for all these objects which were created in the
current interpreter.
And since stackless Python has very few interpreters
(after the imports, there is almost just one),
very many objects would have this nice property.

I don't know how to handle calls to unknown functions.
Perhaps, parameters to such functions must me recorded
in some structure which marks them as "unsafe to collect".

What do you think?

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home




More information about the Python-list mailing list