Re: SMOB tutorial for Scwm and Guile

[Greg Harvey <Greg.Harvey@thezone.net>]

Greg Badros <gjb@cs.washington.edu> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > > MAKING AN INSTANCE OF A SMOB
> > > 
> > > So, after registering our SMOB, the Guile interpreter knows how to deal
> > > with SMOBs of that type, but we still have not seen how to create a new
> > > object of a SMOB class.  We did, however, see what a SMOB object is
> > > stored internally in an earlier section.  In fact, Guile has no special
> > > help for constructing SMOB instances--- you simply write a primitive
> > > procedure that builds a CONS cell with the appropriate id field and a
> > > pointer to just C structure, and return that SCM object.  Since this is
> > > error-prone, Scwm provides a helper macro, SCWM_NEWCELL_SMOB:
> > > 
> > > #define SCWM_NEWCELL_SMOB(ANSWER,ID,PSMOB) \
> > >    do { \
> > >      SCM_NEWCELL((ANSWER)); \
> > >      SCM_SETCAR((ANSWER),(ID)); \
> > >      SCM_SETCDR((ANSWER),(SCM) (PSMOB)); \
> > >    } while (0)
> > 
> > This isn't all that safe, unless you change the gc slightly;
> > this would require putting SCM_SETCDR first (though if things go
> > wrong, either way is going to give you, at best, a fairly cryptic
> > error). 
> 
> So what is the right fix?  We actually call gh_defer_ints(),
> gh_allow_ints() before and after the above macro invocation, and I was
> thinking of folding them into the macro, but I remember something about
> that not being necessary.  

Doing it that way (with defer ints) should be safe. The right way
(which has nothing to do with this code, really) is to just remove the
line of scm_gc_mark that sets the cdr of a freecell to SCM_EOL, then
changing the order.

> Is just switching the order of SETCDR and
> SETCAR sufficient?  

Not currently (it would suck just as bad if the gc chucked out your
memory as if it tried to trace an incomplete object).

> I can see that if a GC happened between the SETCAR
> and the SETCDR that would be bad, but I'm not clear on how asynchronous
> the GC is.

Not having much use for threads & pals, I'm not totally sure if it's
more conceptually bad, or a real dangerous bug waiting to happen
(though native threads support would likely break any code that wasn't
cautious about this).

> That this is tricky should be evidence that GUILE should provde the
> above macro, not applications.

Yep, it should. There are currently too many places where you have to
have a somewhat intimate knowledge of the inner workings of Guile to
get things right (and the lack of documentation doesn't help a bit).

-- 
Greg H