GC question

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

GC question

Erik Sandberg
Hi,

Does anyone know if it is safe to call scm_gc_unprotect_object inside the
destructor of a smob? I know it sounds a bit weird to do so, but it's the
cleanest solution I can find to a problem.

Erik


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GC question

Han-Wen Nienhuys
Erik Sandberg wrote:
> Hi,
>
> Does anyone know if it is safe to call scm_gc_unprotect_object inside the
> destructor of a smob? I know it sounds a bit weird to do so, but it's the
> cleanest solution I can find to a problem.

it will generate an error in GUILE 1.7 CVS. This should never be
necessary anyway.




--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GC question

Erik Sandberg
On Wednesday 17 August 2005 16.08, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> > Hi,
> >
> > Does anyone know if it is safe to call scm_gc_unprotect_object inside the
> > destructor of a smob? I know it sounds a bit weird to do so, but it's the
> > cleanest solution I can find to a problem.
>
> it will generate an error in GUILE 1.7 CVS. This should never be
> necessary anyway.

It's related to mixing smobs and non-smobs.

A non-smob class A has a reference to a smob B. A makes sure to gc_protect B,
and in A's destructor, B is gc_unprotected. (I don't see another way of
saving B from GC.)

class A {
  SCM b_;
  A() { b_ = get_b (); scm_gc_protect_object (b_); }
  ~A() { scm_gc_unprotect_object (b_); }
  ...
};

Now if a third smob C contains an A object, as in

class C {
  A a_;
  ...
  DECLARE_SMOBS (C);
};

.. then A's gc_unprotect will be called during the gc sweep.

Is my problem related to the smob macros in Lilypond? (if not, I should ask on
guile-user instead).

--
Erik


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GC question

Han-Wen Nienhuys
Erik Sandberg wrote:

> class A {
>   SCM b_;
>   A() { b_ = get_b (); scm_gc_protect_object (b_); }
>   ~A() { scm_gc_unprotect_object (b_); }
>   ...
> };
>
> Now if a third smob C contains an A object, as in
>
> class C {
>   A a_;
>   ...
>   DECLARE_SMOBS (C);
> };
>
> .. then A's gc_unprotect will be called during the gc sweep.
>
> Is my problem related to the smob macros in Lilypond? (if not, I should ask on
> guile-user instead).
>

do the following:

   make A::protect() and A::unprotect().

In C::C call A::unprotect, and use C::mark to mark the smob. You will
also need machinery to make sure unprotect() isn't called if the B is no
longer protected.

--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GC question

Erik Sandberg
On Thursday 18 August 2005 11.25, Han-Wen Nienhuys wrote:

> Erik Sandberg wrote:
> > class A {
> >   SCM b_;
> >   A() { b_ = get_b (); scm_gc_protect_object (b_); }
> >   ~A() { scm_gc_unprotect_object (b_); }
> >   ...
> > };
> >
> > Now if a third smob C contains an A object, as in
> >
> > class C {
> >   A a_;
> >   ...
> >   DECLARE_SMOBS (C);
> > };
> >
> > .. then A's gc_unprotect will be called during the gc sweep.
> >
> > Is my problem related to the smob macros in Lilypond? (if not, I should
> > ask on guile-user instead).
>
> do the following:
>
>    make A::protect() and A::unprotect().
>
> In C::C call A::unprotect, and use C::mark to mark the smob. You will
> also need machinery to make sure unprotect() isn't called if the B is no
> longer protected.

The problem is that A and B are created implicitly by macros, and C can
contain more than one such macro. Hence, it's difficult for the creator of C
to know what to mark. I think it's partially solvable by adding even more
disgusting macros (creating a static linked list of relative pointers to
members to be marked by mark_smob), but I think I'll stick to a different
inefficient & simple solution for now.

--
Erik


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel