From: Marius Vollmer <mvo@zagadka.ping.de>
Cc: guile-user@gnu.org
Subject: Re: out-of-order GC
Date: 01 Jan 2003 22:22:21 +0100 [thread overview]
Message-ID: <87bs30h8fm.fsf@zagadka.ping.de> (raw)
In-Reply-To: <Pine.LNX.4.30.0301011154140.1884-100000@urd.norna.redhog.org>
Egil Moeller <redhog@redhog.org> writes:
> > Fortunately, resource smobs can check, in their free functions,
> > whether this has happened, by looking at the SCM_TYP16 of their
> > reference to the display smob. If the display smob is still valid,
> > this will be scm_tc16_xdisplay, and the relevant X resource should
> > be freed as normal. If the display smob has been freed earlier in
> > this sweep, GC will have set its SCM_TYP16 to scm_tc_free_cell;
> > this indicates that XCloseDisplay has already been called, and so
> > the relevant X resource no longer needs to be freed. */
>
> Aha, so that's how it should be done.
Hmm. I think it would be better not to rely on this detail of how the
GC works. I don't think we want to guarantee that you can always tell
whether a particular cell has been freed during this GC. For example,
we might change the GC so that it gives heap segments back to the OS
when all their cells are on a freelist. These cells are then `off
limits' to the application. Or the GC might play tricks with the MMU
and make free cells write-only...
You could simply use scm_tc_free_cell anyway, being prepared to find a
new solution when your hack stops working, or you could add a
reference count to the C connection struct and point directly to it
from the C transaction object. The connection could then stay around
long enough. There are probably other solutions as well.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
prev parent reply other threads:[~2003-01-01 21:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-29 16:36 out-of-order GC Egil Moeller
2002-12-30 13:36 ` Greg Troxel
2002-12-30 14:05 ` Egil Moeller
2002-12-31 3:06 ` Matt Hellige
2002-12-31 20:13 ` Neil Jerram
2003-01-01 10:57 ` Egil Moeller
2003-01-01 17:58 ` Neil Jerram
2003-01-01 21:22 ` Marius Vollmer [this message]
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=87bs30h8fm.fsf@zagadka.ping.de \
--to=mvo@zagadka.ping.de \
--cc=guile-user@gnu.org \
/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).