out-of-order GC

out-of-order GC

[Egil Moeller]

Hi!
I have a problem developing an extension library to guile in C: I have two
types of SMOBs, of which the first one represents a connection, and the
second one a transaction on such a connection. A transaction is created
by sending some data over the connection, and a handle will be returned,
which is then sent back over the connection to close the transaction.
Thus, the transaction-SMOB must contain a reference to the connection-SMOB
that was used to create it. The problem araises if no external reference
exist neither to a connection, nor to a transaction on that connection,
and both of them lost their external referrences before a GC. In this
case, it might happend that the connection-SMOB i first freed, and then
the transaction-SMOB. But the transaction-SMOB-free-routine will now
crash, as it tries to access the connection, which has allready been
deleted. How should I solve this problem? It is sufficient if the
transaction-SMOB-free-routine is notified about that the connection was
previously closed, and thus it is able to not take any action to send the
close-transaction-command (it would be nicer, thought, if one could force
the transaction-SMOB-free-routine to be called _before_ the
connection-SMOB-free-routine).
Regards,
Egil

-- 
http://redhog.org
GPG Public key: http://redhog.org/PGP%20Public%20key.asc
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: out-of-order GC

[Greg Troxel]

It sounds like your problem is that the transaction SMOB is holding a
reference to the connection SMOB, but that the GC system is not aware
of this.  The transaction SMOB's mark routine should return (or call
mark on) the connection SMOB.  Thus, until all the transaction SMOBs
are freed, the connection SMOB will still be in use.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: out-of-order GC

[Egil Moeller]

> It sounds like your problem is that the transaction SMOB is holding a
> reference to the connection SMOB, but that the GC system is not aware
> of this.  The transaction SMOB's mark routine should return (or call
> mark on) the connection SMOB.  Thus, until all the transaction SMOBs
> are freed, the connection SMOB will still be in use.

I thought so first, but it turned out, I did have a mark-routine for the
transaction-SMOB that did return the connection-SMOB. The problem
thus never araised when there was a referense to the transaction-SMOB,
only when there where no reference to neither one any more...

-- 
http://redhog.org
GPG Public key: http://redhog.org/PGP%20Public%20key.asc
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: out-of-order GC

[Matt Hellige]

[Egil Moeller <redhog@redhog.org>]
> > It sounds like your problem is that the transaction SMOB is holding a
> > reference to the connection SMOB, but that the GC system is not aware
> > of this.  The transaction SMOB's mark routine should return (or call
> > mark on) the connection SMOB.  Thus, until all the transaction SMOBs
> > are freed, the connection SMOB will still be in use.
> 
> I thought so first, but it turned out, I did have a mark-routine for the
> transaction-SMOB that did return the connection-SMOB. The problem
> thus never araised when there was a referense to the transaction-SMOB,
> only when there where no reference to neither one any more...
> 

Yes, I suspected at first that marking was the problem, but I think
it's not. As you say, the problem as you described would still
possibly occur when both smobs are ready to be collected. I think you
could use a trick similar to the one described in the dia example:
http://www.gnu.org/software/guile/docs/guile-ref/Programming-Overview.html

That way, the transaction smob will always refer to a valid structure
wrapping a connection smob. The connection smob should point to the
same structure, and if freed, should indicate such in the wrapper.
Then the transaction smob will notice that its connection has been
freed and can take appropriate action, freeing the wrapper structure
in the process.

The extra layer of indirection shouldn't be too expensive, and it
should solve your problem.

Matt

-- 
Matt Hellige                  matt@immute.net
http://matt.immute.net


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: out-of-order GC

[Neil Jerram]

>>>>> "Egil" == Egil Moeller <redhog@redhog.org> writes:

    Egil> The problem thus never araised when there was a referense to
    Egil> the transaction-SMOB, only when there where no reference to
    Egil> neither one any more...

This is identical to the problem that I had in guile-xlib (with
connection -> Display and transaction -> window/pixmap/whatever).
Here is the relevant comment from xlib.c...

/* Note on garbage collection and freeing of X resources.

   The one wrinkle in implementing automatic freeing of X resources is
   that almost all X resources depend on a valid display, so we have
   to be careful that the display resource is always freed (using
   XCloseDisplay) last of all.

   In most cases this is handled by having resource smobs include a
   reference to the display smob.  But there is still a problem when
   all remaining X resource references are dropped between one GC
   cycle and the next: when this happens, the next GC sweep could free
   the display smob before it gets to some of the other resource
   smobs.

   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. */

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: out-of-order GC

[Egil Moeller]

>    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. Is it the pointer (on the resource
SMOB), or the diplay SMOB itself that is marked? And in the latter cae,
what if the space has allready been reused, or can't that happend? And
what is the name of the C function to check the pointer for what type it
is?

Regards,
Egil

-- 
http://redhog.org
GPG Public key: http://redhog.org/PGP%20Public%20key.asc
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: out-of-order GC

[Neil Jerram]

>>>>> "Egil" == Egil Moeller <redhog@redhog.org> writes:

    Egil> Aha, so that's how it should be done. Is it the pointer (on
    Egil> the resource SMOB), or the diplay SMOB itself that is
    Egil> marked?

The display SMOB (i.e. the SMOB cells on the heap).

    Egil> And in the latter cae, what if the space has
    Egil> allready been reused, or can't that happend?

If I understand correctly, this whole scenario is only difficult if
both "resource" and "display" SMOBs are GC'd in the same GC cycle.  So
it isn't possible that the cells used for the display SMOB are already
being reused.

(I think; it would be good if a GC expert could check my logic here.)

    Egil> And what is the
    Egil> name of the C function to check the pointer for what type it
    Egil> is?

There isn't a function.  My code does this:

  if ((SCM_TYP16 (win->dsp) == scm_tc16_xdisplay) &&
      ...)
    scm_x_destroy_window_x (window);

If it followed the pattern in most of libguile, it should instead be:

#define SCM_XDISPLAYP(x)  SCM_TYP16_PREDICATE (scm_tc16_xdisplay, x)

  if (SCM_XDISPLAYP (win->dsp) &&
      ...)
    scm_x_destroy_window_x (window);

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: out-of-order GC

[Marius Vollmer]

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