From: Andy Wingo <wingo@pobox.com>
To: hanwen@xs4all.nl
Cc: guile-devel@gnu.org
Subject: Re: the new gc asserts in master
Date: Wed, 27 Aug 2008 12:00:13 -0700 [thread overview]
Message-ID: <m3sksqp9ky.fsf@pobox.com> (raw)
In-Reply-To: <g93mnl$69n$1@ger.gmane.org> (Han-Wen Nienhuys's message of "Wed, 27 Aug 2008 11:00:09 -0300")
Hi,
On Wed 27 Aug 2008 07:00, Han-Wen Nienhuys <hanwen@xs4all.nl> 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/
next prev parent reply other threads:[~2008-08-27 19:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-26 20:12 the new gc asserts in master Andy Wingo
2008-08-27 2:12 ` Han-Wen Nienhuys
2008-08-27 2:41 ` Han-Wen Nienhuys
2008-08-27 7:43 ` Ludovic Courtès
2008-08-27 14:00 ` Han-Wen Nienhuys
2008-08-27 15:38 ` Ludovic Courtès
2008-08-28 4:08 ` Han-Wen Nienhuys
2008-08-28 4:14 ` Han-Wen Nienhuys
2008-08-28 7:15 ` Ludovic Courtès
2008-09-03 4:39 ` Han-Wen Nienhuys
2008-09-03 8:12 ` Ludovic Courtès
2008-09-03 13:39 ` Han-Wen Nienhuys
2008-09-03 14:49 ` Ludovic Courtès
2008-09-04 2:17 ` Han-Wen Nienhuys
2008-08-27 19:00 ` Andy Wingo [this message]
2008-08-27 20:22 ` Andy Wingo
2008-08-28 4:33 ` Han-Wen Nienhuys
2008-08-28 14:17 ` Ludovic Courtès
2008-08-28 4:04 ` Han-Wen Nienhuys
2008-08-28 13:20 ` Han-Wen Nienhuys
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3sksqp9ky.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=hanwen@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).