Re: Critical sections and marking of free cells

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

On Thu, 12 Nov 1998, Mikael Djurfeldt wrote:

> In Guile, at most places where we make new smobs, we have pieces of
> code like this:
> 
> SCM_NEWCELL (z);
> SCM_DEFER_INTS;
> SCM_SETCAR (z, scm_tc16_<name>);
> SCM_SETCDR (z, <malloced memory>);
> SCM_ALLOW_INTS;
> 
> It seems to me that these critical sections can be removed (that is,
> we can remove SCM_DEFER/ALLOW_INTS) if we remove one line (846) from
> gc.c:
> 
> 	case scm_tc_free_cell:
> 	  /* printf("found free_cell %X ", ptr); fflush(stdout); */
>     --->  SCM_SETCDR (ptr, SCM_EOL); <---
> 	  break;
> 
> *and* switch the order between the SETCAR and SETCDR, writing, instead
> of the above:
> 
> SCM_NEWCELL (z);
> SCM_SETCDR (z, <malloced memory>);
> SCM_SETCAR (z, scm_tc16_<name>);
> 
> Have I missed something, or can we actually implement this change?

I think a more radical change would be better: Although I've been using
guile with smobs for a while now, I'm not sure I got the thing with the
critical sections right at every place.

I'd rather propose a change in the macro SCM_NEWCELL, which automatically
takes care of the whole issue, for example:

#define SCM_NEWCELL(scm, car, cdr) { SCM_NEWCELL_OLD(scm); \
                                     SCM_DEFER_INTS;       \
                                     SCM_SETCAR(scm, car); \
                                     SCM_SETCDR(scm, cdr); \
                                     SCM_ALLOW_INTS; }

or, making use of your suggestion

#define SCM_NEWCELL(scm, car, cdr) { SCM_NEWCELL_OLD(scm); \
                                     SCM_SETCDR(scm, cdr); \
                                     SCM_SETCAR(scm, car); }

The current way this is done forces users to use such a pattern all the
time, which means degrading them to error-prone macro processors which are
completely lost as soon as a failure occurs. I up to now did not encounter
problems due to some forgotten DEFER-ALLOW pair, but I'm pretty sure it
would take me a lot of time to figure out what's wrong.

Best regards, 
Dirk Herrmann