[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with smobs
From: |
Joris van der Hoeven |
Subject: |
Re: Problem with smobs |
Date: |
Tue, 30 May 2006 12:09:59 +0200 |
User-agent: |
Mutt/1.5.9i |
On Tue, May 30, 2006 at 11:53:34AM +0200, Mikael Djurfeldt wrote:
> >In other words: printing the smob prevents the memory from being released.
> >Does "display" admit some hidden (and undocumented) side effects?
> >Did I do something wrong? Is this a bug in Guile?
> >Any help would be appreciated.
>
> I wouldn't call this a bug and wouldn't call it undocumented. The
> garbage collector only guarantees that it doesn't free things which
> you can reference. It doesn't guarantee whether to or when to free
> things which lack a reference.
>
> In this case my guess is that some reference to your smob remains on
> the stack or in some data structure associated with printing (like the
> print-state) immediately after printing. That reference will very
> likely pretty soon disappear after some further execution.
Hmm, printing "\n" does not seem to suffice. But after recursively
printing a large object, the memory gets freed. It might be good to add
a note about this in the smob documentation, because one of the first
tests one usually does after writing a smob type is to print some smobs.
If objects don't get freed, even after a gc, then this is somewhat confusing.
So I still would call this an undocument side-effect of "display".
How much precisely is kept on the stack or in print-states?
Thanks for your quick reply, Joris
Re: Problem with smobs, R. Mattes, 2006/05/30