Re: the new gc asserts in master

[Andy Wingo]

Hi,

On Wed 27 Aug 2008 07:00, Han-Wen Nienhuys <address@hidden> writes:

>>>>     http://thread.gmane.org/gmane.lisp.guile.user/6372
>
> I think reference counting is the correct solution for this, as far as
> I understand the problem from the quoted message.

I don't think so; the use case is that (1) we don't want to prevent the
C object from being freed, so we don't want to hold a reference on the C
object; but (2) we do want to know when it is freed, so we can release
our cache; but (3) we want to get the scheme object back if the object
has not in fact been swept.

But the laziness of the sweeper prevents us from knowing whether the
cache that we have is in fact accessible, because there is a time
between the mark phase (in which the object might become sweepable) and
when the smob's free function is called in the sweep phase (which would
invalidate the cache).

> The use of scm_gc_mark() outside of GC is fundamentally broken, since it
> creates race conditions in the presence of threads.

I was not aware that this was the case. 

My impression was that the mark phase is global; it requires all threads
that were in guile mode to go dormant, and those that were not in guile
mode cannot enter guile mode until the mark is complete.

So if I have a thread in guile mode, it is not in the mark phase, hence
no race. Also, it would not be sweeping; I can check the cache and
retrieve and mark the object without the thread of interest doing a
sweep(). But perhaps some other thread would sweep that card, in which
case I guess I can see where the problem would come in.

It's very irksome that I missed this bit in the documentation.

So, my proposal to fix this is to expose the sweep mutex as part of the
API somehow, perhaps as e.g.

   void* scm_with_sweep_mutex (void* (*with_mutex_func)(void*), void*);

or so. How do you feel about this? I know it constrains your GC
implementation, but threads + lazy sweeping + integrating with C
libraries = exposing some minimal amount of low-level details.

Regards,

Andy
-- 
http://wingolog.org/