Hi, On Wed 27 Aug 2008 07:00, Han-Wen Nienhuys <[EMAIL PROTECTED]> 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/
