Re: Garbage collection of extended data types

From: David Fox <fox_at_GRAPHICS.CS.NYU.EDU>
Date: Mon, 2 Oct 95 07:41:58 EDT

Erick Gallesio writes:

> > David Fox writes
> > I have some C++ structures that are used as extended scheme
> > types from STk, and I use the mark and free functions to
> > do garbage collection of them, however...
> >
> > Some of them are fairly complex, and during the marking phase
> > I traverse them to find which ones are live. I even have a
> > mark flag in them to reduce unnecessary traversals. Problem
> > is, I don't know when the marking phase is over so I can reset
> > my marks. Is there a way to tell? Should there be?
>
> Normally, a structure should not be scaned twice, is it your case
> or is it due to the complex nature of your extension?

Yes, there are many paths from scheme to each C++ object, and vice
versa. I have it more or less under control by seting a mark when
I start GC-ing a given C++ object and then resetting it when I'm
finished, but it would be even better if I could reset it when the
GC sweep phase was over.

> BTW, I plan to add (soon) a way to assign a Scheme handler for each
> POSIX signal and for GC. The idea is to have a hook so that user
> can add code upon signal reception (of course the notion of signal
> will be extended to the GC). What people think of this, and what
> syntax would be more convenient?

Yes, I would support such an extension. This sort of relates to
my other mail where I added hooks to handle X events to toplevel.c.
There I do a select on each X server's file descriptor as well as
on the console input file descripter, and I obtain the next expiring
timer (if any) from a heap of timers to use as the timeout value
for select. When the select returns I grab the event and pass the
info to a function called "handle". It would be nice to receive
signals this way as well. Or some other way, I'm not picky. Just
as long as I can receive everything the same way.
Received on Mon Oct 02 1995 - 12:44:09 CET