From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29253 invoked by alias); 14 May 2003 01:17:10 -0000 Mailing-List: contact guile-gtk-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: guile-gtk-owner@sources.redhat.com Received: (qmail 29245 invoked from network); 14 May 2003 01:17:09 -0000 Received: from unknown (HELO lumo.pacujo.net) (209.77.185.85) by sources.redhat.com with SMTP; 14 May 2003 01:17:09 -0000 Received: (from marko@localhost) by lumo.pacujo.net (8.11.6/8.11.6/SuSE Linux 0.5) id h4E18oP08716; Tue, 13 May 2003 18:08:50 -0700 To: guile-gtk@sources.redhat.com Subject: Re: Introduced destructors and finalized GdkCursor References: From: Marko Rauhamaa Date: Wed, 14 May 2003 01:17:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-q2/txt/msg00067.txt.bz2 Marko Rauhamaa : > 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/