Re: Smob documentation

[Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> could someone please add a section to data-rep.texi
> that describes how and why it is neccesary to inhibit
> garbage collection while creating a smob.  It took
> me one hour to find the following bug:
> 
> 
> 
> [...]
> 
>   scm_block_gc = 1; /* prevent memoized from being gc'ed */
>   {
>     eval_environment->memoized = 
>       scm_make_doubly_weak_hash_table((SCM) SCM_MAKINUM (scm_symhash_dim));
> 
>     eval_environment_smob = scm_make_environment(eval_environment);
>   }
>   scm_block_gc = 0;
> 
>   return eval_environment_smob;
> 
> [...]

The problem you experienced is not specific to smobs.  When handling
SCM objects from C you always have to keep in mind what the garbage
collector can see.  The garbage collector sees what is stored on the
heap + a set of special locations (such as current input port etc) +
the stack.  Any SCM object which can't be reached from those locations
will be collected.

You should not block GC above, but instead make sure that the hash
table can be reached by the GC, e.g.:

{
  eval_environment_smob = scm_make_environment(eval_environment);
  eval_environment->memoized =
    scm_make_doubly_weak_hash_table((SCM) SCM_MAKINUM (scm_symhash_dim));
}

eval_environment_smob can be seen by the GC because since because it
is returned by the function it has to stay on the stack or in some
CPU register (which will be pushed onto the stack during GC).
(Note that scm_make_environment must initialize the empty memoized
slot to some acceptable SCM value.)

The hash table will be seen because it now can be reached through
eval_environment_smob.

Yes, this should be documented, preferably in guile-ref.

/mdj