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] |
> 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.