This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Marking smobs for GC



> But when I redefine the temp variable, that window is subject to
> garbage collection. What I would like is that the window structure
> and the smob associated with it persist.

The simplest way to tell the GC to keep an object alive is to actually
make it live.  :)  That is, just point to it somehow.

For example, you could call scm_protect_object and
scm_unprotect_object as needed.

Or, you could allocate a pair, call scm_protect_object once on it, and
then use it as the head of a list of the smobs you want to keep alive.

Or, if fltk maintains a list of windows somewhere, you could make a
new smob type for that window list itself, make an instance of it, and
then call scm_protect_object on the instance.  Then that smob's
marking function would walk the fltk list, and mark the smobs for the
live windows.

The point is, don't try to lie to the GC about what's alive and what
isn't.  Whenever you find yourself worrying that the GC is going to
free something when you don't want it to, it's almost always the case
that your program has some path to the object that the GC doesn't know
about.  And you should either tell it about the path, or add calls to
scm_protect_object and scm_unprotect_object that tell the GC
explicitly about the lifetime of the object.


> Another quick question -- the documentation "Data Representation in 
> Guile" says that there are patterns of acceptable required and
> optional parameters that can be passed to a function.  Are these
> patterns documents, or does anyone know what they are?

They ought to be documented, but basically, if you're out of bounds,
you'll get an error when you try to create the procedure.  If you're
not doing an extreme number of arguments, post to this list, and I'll
extend Guile to handle it.  If you are doing something weird, then
define your function to take a ``rest'' argument, and parse the
arguments yourself.