Re: Scm_sloppy_assq mostly fixed, still real slow

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

> With the new mechanism, yes.  And, I think this is a good thing,
> since calls to protect/unprotect nest.  Thus, if an object was
> protected from two different places, but (erroneously) freed too
> often, there might still be some code that relies on the object
> still being protected.

No, I currently use it the other way 'round.  I first unprotect
individual objects and then, when a lock is removed the complete chain
is unprotected.  Thus an object can be unprotected twice.  This is a
quite common situation.

However, the choice is arbitrary and the old code was also correct.  I
don't argue against the change but I think such changes should be
announced somwhere, at least the documentation should be updated:


/* Protect OBJ from the garbage collector.  OBJ will not be freed,
   even if all other references are dropped, until someone applies
   scm_unprotect_object to it.  This function returns OBJ.

   Calls to scm_protect_object and scm_unprotect_object nest.  For
   every object O, there is a counter which scm_protect_object(O)
   increments and scm_unprotect_object(O) decrements, if it is greater
   than zero.  Otherwise, undefined behaviour occurs.  If an object's
   counter is greater than zero, the garbage collector will not free
   it.  */


Jost