This is the mail archive of the
guile-gtk@sources.redhat.com
mailing list for the Guile project.
Re: Introduced destructors and finalized GdkCursor
- From: Marko Rauhamaa <marko at pacujo dot net>
- To: guile-gtk at sources dot redhat dot com
- Date: 13 May 2003 18:08:50 -0700
- Subject: Re: Introduced destructors and finalized GdkCursor
- References: <m3ptmso2vo.fsf@lumo.pacujo.net>
Marko Rauhamaa <marko@pacujo.net>:
> Summary: Introduced destructors and finalized GdkCursor.
>
> Details:
>
> - build-guile-gtk-1.2: The defs files didn't specify destructors.
> Instead, the garbage collector was trusted to release resources. This
> is the right strategy as long as the resource is a piece of client
> RAM. However, we must release X server resources as soon as they are
> no longer needed.
>
> I have now introduced a new option for define-boxed and
> define-struct: (physical #t). When set, the function specified in the
> free option becomes callable from guile code. The proxy object stays
> alive, but any reference to it causes an assertion to fail.
>
> - gdk-1.2.defs: As a first application of destructors, I added the
> (physical #t) option to GdkCursor.
In light of my recent revelation regarding the design of the boxed
types, I have to backtrack from this scheme and take out the whole
"physical" thing.
Theoretically, the problem is real -- you could design an application
that forces the X server to store a large number of unused resources.
However,
1. There is no way to fix the problem.
2. In practice, the problem is not likely get bad since the main case,
GdkWindow, happens to have the right kind of destructor
(gdk_window_destroy).
Here's the reason for my confusion: I thought there was a one-to-one
mapping between the boxed smobs and GDK objects. It turns out multiple
smobs can share the same GDK object, and that design cannot be changed.
Marko
--
Marko Rauhamaa mailto:marko@pacujo.net http://pacujo.net/marko/