12 Feb
2004
12 Feb
'04
7:42 a.m.
On Thu, Feb 12, 2004 at 09:24:28AM +0100, Kjetil Svalastog Matheussen wrote:
note that reference counting behavior doesn't differ that
much from a sweeping gc: as soon as a count to a large
object tree drops to zero the whole tree will be freed
instantly, causing an indeterminate delay in execution,
unless you defer free operations until there is time to
perform them. additionally, AFAIK python uses malloc/free
for memory management, which are inherently non-realtime.
i'm not sure if turning off gc is a real solution for (long
running) musical applications. why'd you have a gc in the
first place? when do you turn it back on? what about
applications that constantly create many small objects?
realtime gc algorithms OTOH have been around for some time
(baker's initial treadmill paper is from '78) and can even
deliver hard realtime 'performance'. nothing's for free,
though: they usually impose more restrictions on a language
runtime, e.g. WRT foreign language interfaces, and probably
suffer from internal fragmentation more than other
(compacting) algorithms.
<sk>
I don't
know about other garbage-collected languages, but
there is no way to temporarily disable GC in Python,
nor any way to force it to run at a particular time.
Yes, but python have a reference-count garbage collector, so
the problem shouldn't matter for python.