This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gc suggestions


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]