Re: New smob interface

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

Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:

> scm_size_t WINDOW_free (SCM object)
> {
>   WINDOW *w;
>   w = SCM2WINDOW (object);
>   gh_defer_ints ();
>   delwin (w);
>   gh_allow_ints ();
>   return sizeof (WINDOW);
> }
> 
> 
> scm_set_smob_free (WINDOW_type, &WINDOW_free);
> 
> SCM WINDOW2SCM (WINDOW *w)
> {
>  SCM z;
>  SCM_NEWSMOB (z, WINDOW_type, w);
>  return z;
> }

Ehum...

I just realized a problem here...  Your free function returns the size
of a window structure.  This information is used by the GC to monitor
memory usage in order to know when to trigger GC.  It tells the GC
that sizeof (WINDOW) bytes have been returned to the system memory
pool.

But, we never told it that sizeof (WINDOW) bytes was allocate in the
first place!  This is normally handled inside scm_must_malloc.  (All
Guile objects have their storage allocated using that call.)

So, the question is how to handle situations when the user application
wants to allocate memory.

I guess there are two options:

1. Specify size 0 in this case, so that the GC never is aware of this
   memory.

2. Tell the GC about foreignly allocated memory.  This could either be
   made through a dedicated call/macro or implicitly in a sibling
   function to scm_make_smob which takes two args, the second being a
   pointer to the data allocated.

I guess Guile's GC performance would benefit from alternative two.

What does the GC experts say about this?  Greg?

(Everybody is of course welcome to participate in improving the
 interface, though I'm not sure I can answer all emails.)