This is the mail archive of the guile@cygnus.com 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 Garbage Collection for Smobs



> One problem that I was having with the old system
> (and still am with the new) is that when I store a list
> of substrings within my table and I go through a mark stage
> where I call scm_gc_mark() on any data in the table
> I get a segmentation violation in the garbage collector (!)

Your table is your new smob type, yes?  It keeps several lists of
strings, and these lists and strings are ordinary Scheme lists and
strings?

Could you post your marker function?


> I still can't pin down any details more than that but
> if I store the substrings directly (not in a list) then it
> doesn't crash even though my code does exactly the same thing
> (as soon as I get time, I'll fiddle around and get something
> small that demonstrates this effect).
> Are there gotchas in using (make-shared-substring) and
> (substring)? They are essential for working with regexp stuff.

Not really; the instructions in the data-rep essay should work for all
Guile types.

> Something (probably unrelated) that I noticed is that
> if your smob checks it's SCM_TYP16() value during garbage
> collection then it will see the 0x80 flag bit and might fail
> sanity checks. The safest thing is to mask out the flag bit:

The essay talks about that gotcha.  There should be a note about this
in the Typechecking section, too...

  Note that, since a smob's mark bit lives in its CAR, along with the
  smob's type tag, the technique for checking the type of a smob
  described in section Typechecking will not necessarily work during
  GC. If you need to find out whether a given object is a particular
  smob type during GC, use the following macro:

  Macro: void SCM_GCTYP16 (SCM x) 
	Return the type bits of the smob x, with the mark bit clear. 

	Use this macro instead of SCM_CAR to check the type of a smob
	during GC. Usually, only code called by the smob's mark function
	need worry about this.

  It is usually a good idea to minimize the amount of processing done
  during garbage collection; keep mark and free functions very
  simple. Since collections occur at unpredictable times, it is easy for
  any unusual activity to interfere with normal code.