This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: gc suggestions
- To: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Subject: Re: gc suggestions
- From: Michael Livshin <mlivshin at bigfoot dot com>
- Date: 27 Jun 2000 14:09:41 +0200
- Cc: Guile Mailing List <guile at sourceware dot cygnus dot com>
- Organization: who? me?
- References: <Pine.LNX.4.21.0006271254340.22781-100000@marvin.ida.ing.tu-bs.de>
Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> Hello list.
hello Dirk!
> Problem:
> The variable scm_gc_heap_lock blocks, if non-zero, the creation of new
> heap segments, except for the very first heap segment, which is created
> independently. This variable is initialized to zero, which means, that
> even during the startup phase of guile new heap segments could be
> potentially added, for example if the initial heap segment appears to be
> too small.
>
> Thus:
> I suggest to initialize scm_gc_heap_lock with 1 until scm_init_gc is
> performed. Then, we just have to make sure that all initialization code
> that scm_init_gc depends on is performed before in init.c. Thus, we
> achieve the following goals:
> - the initialization of the asyncs is performed at the right place.
> - if the initial heap segment appears to be too small to be suffifient
> until scm_init_gc is performed, guile aborts and can be fixed in order
> to enlarge the initial heap segment.
this seems to be a slightly roundabout way of doing things. a better
solution, IMHO, would be to still allow new heap segment allocations
during startup, but to disallow GC. thoughts? (I didn't think about
this for very long).
--
Entropy isn't what it used to be.