This is the mail archive of the 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: New smob interface

Mikael Djurfeldt <> writes:

> Klaus Schilling <> 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 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.)

Here you should use scm_done_malloc. There should also be a
scm_done_free call, so that you don't have to return the size freed to
the gc, which can be unwieldy if you have a large, dynamic
structure (I think it's a bit gross, anyway ;). 

It's sort of not quite on the topic, but I think we should also be
providing two sets of allocation functions (in the thing sources, I've
got this added... I changed them to scm_obj_* and scm_nonobj_*, but
I'm sure better names can be devised :); the nonobj_* functions don't
register the size allocated with the gc, but they do do the error
checking (and possible gc) of the obj_* functions. scm_must_malloc is
often used incorrectly (even in the guile sources... scm_getcwd in
filesys.c is one example on the top of the grep :).

> 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?

I'm sort of split over what we should be doing with malloc and pals,
but the best way is probably to stick with having the gc know about
any allocations that create an object under the gc's
control. scm_done_malloc, with an additional scm_done_free could
provide the actual mechanism... I think the method you pointed out in
a later mail provides a nice interface for it.


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