Re: SCM objects on the heap?

[Dirk Herrmann <dirk@ida.ing.tu-bs.de>]

On Mon, 28 Sep 1998, Maciej Stachowiak wrote:

> > Am I right in assuming that SCM objects are only protected from gc as long
> > as they are on the stack and not if they are on the heap?
> 
> If SCM values are on the stack, they are autiomatically protected
> against gc. If they are on the heap, they must be protected explictly,
> such as with scm_protect_object()/scm_unprotect_object(). One problem
> with scm_[un]protect_object for your application (and others) is that 

Oops, parts of your message seem to have disappeared here.

> > example (just sketched):
> > 
> > SCM* p = new SCM[100];         /* C++ style, for C use malloc */
> > for (unsigned int i = 0; i < 100; ++i)
> >     p[i] = gh_cons(SCM_BOOL_T, SCM_BOOL_T);
> > 
> > If I am right, later accesses to p are not guaranteed to work with current
> > guile, since the SCM objects referencing the pairs will not be detected
> > during gc.
> > 
> 
> Correct, unless you protect each of the slots in the array
> explicitly. This is undoubtedly quite a pain in this case. Maybe Guile
> could use a scm_protect_range(void *addr, size_t size) which would
> conservatively protect an address range against GC until that range is
> unprotected (I guess this would require a unique handle return value
> to be passed to scm_unprotect_range).

Thanks for your answer!

I checked the guile source to figure out how scm_protect_object and
scm_unprotect_object work: 

- there is a global list 'scm_protects'
- whenever a new object is to be protected:
  scm_protects = scm_cons(obj scm_protects);

- when an object is to be unprotected:
  scm_delq_x(obj, scm_protects)

Besides the fact that this is a time consuming implementation, it has 
a major problem: regardless of how often an object was protected, a
single call to unprotect will make it subject to gc.

A simple fix was, not to call scm_delq_x, but a function which only
deletes the first occurence of the object from scm_protects.

However, this approach still seems to be quite ineffective: For every
level of protection a new pair is constructed. Wouldn't it make sense to
have a SCM subtype for protected objects, which consist of a pair with a
counter and the 'real' SCM object?

Also, there should be access to this feature through the gh_ interface.

Best regards, 
Dirk Herrmann