From: Marius Vollmer <mvo@zagadka.de>
Subject: Re: scheme closures: crash during garbage collection
Date: Sat, 10 Jun 2006 12:40:47 +0300 [thread overview]
Message-ID: <87mzclmjq8.fsf@zagadka.de> (raw)
In-Reply-To: <e6cqni$4ub$1@sea.gmane.org> (Han-Wen Nienhuys's message of "Fri, 9 Jun 2006 21:54:58 +0000 (UTC)")
hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) writes:
> In article <87odx2ds0o.fsf@ossau.uklinux.net>,
> Neil Jerram <neil@ossau.uklinux.net> wrote:
>
>>[...]
>>It seems to me, though, that the same kind of situation, leading to
>>wanting to call scm_gc_unprotect_object during GC, is likely to arise
>>in any sufficiently complex application, and hence that we should
>>support this within Guile itself.
>>[...]
>>Can people more familiar with the GC code comment on whether this fix
>>is feasible?
>
> No, MV thinks it's a bad idea, and I agree with him.
>
> See
>
> http://thread.gmane.org/gmane.lisp.guile.devel/4117/focus=4160
Yep, and let me elaborate a bit:
The pair scm_gc_protect_object / scm_gc_unprotect_object can be seen
as being Guile's way to implement reference counting for its objects,
maybe analogous to g_object_ref and g_object_unref for glib's
GObjects. This is true, of course: you can use it to implement
reference counting. However, it is not a good idea, as Guile offers a
better alternative with its mostly-precise mark/sweep garbage
collector.
Using the protec/unprotect functions for references that change with a
high frequency is quite expensive: Guile objects don't contain a
reference count field, and protecting/unprotecting them is implemented
by putting them in a global list and removing them again. Also, the
'reference counts' only need to be correct when the GC actually
happens, and keeping them correct all the time is wasteful in that
sense.
Guile wants you to integrate your objects with its mark/sweep
approach, by providing appropriate smob marking functions, for
example.
The function scm_gc_protect_object is intended for long living, global
objects that are referenced from global C variables. If the global
variable changes often and points to different objects, it might be a
good idea to use scm_gc_register_root instead.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2006-06-10 9:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <64e2f6fe0606081528m4e5f9979yff9b8294ecedf6d2@mail.gmail.com>
2006-06-09 19:54 ` scheme closures: crash during garbage collection Neil Jerram
2006-06-09 21:54 ` Han-Wen Nienhuys
2006-06-10 9:40 ` Marius Vollmer [this message]
2006-06-12 22:34 ` Neil Jerram
2006-06-12 23:33 ` Han-Wen Nienhuys
2006-06-12 23:45 ` Neil Jerram
2006-07-08 15:06 ` Marius Vollmer
2006-07-12 21:48 ` Neil Jerram
2006-10-27 9:49 ` Andy Wingo
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=87mzclmjq8.fsf@zagadka.de \
--to=mvo@zagadka.de \
/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).