From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26149 invoked by alias); 6 Nov 2002 13:17:42 -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 26141 invoked from network); 6 Nov 2002 13:17:39 -0000 Received: from unknown (HELO mail.tiscali.cz) (213.235.135.70) by sources.redhat.com with SMTP; 6 Nov 2002 13:17:39 -0000 Received: from hobitin.ucw.cz (212.11.98.143) by mail.tiscali.cz (6.0.044) id 3DC10A6300116480; Wed, 6 Nov 2002 14:16:16 +0100 Received: from 0rfelyus by hobitin.ucw.cz with local (Exim 3.36 #1 (Debian)) id 189Py3-0000Af-00; Wed, 06 Nov 2002 14:11:35 +0100 To: Stan Pinte Cc: guile-gtk , Subject: Re: implementing guile-gtk drag & drop... References: <87d6pmd7a3.fsf@zagadka.ping.de> <3DC279A4.1010000@wanadoo.be> <87d6pmd7a3.fsf@zagadka.ping.de> <5.1.1.6.0.20021106094931.00a91210@pop.wanadoo.be> From: Daniel Skarda <0rfelyus@ucw.cz> Date: Wed, 06 Nov 2002 05:17:00 -0000 In-Reply-To: <5.1.1.6.0.20021106094931.00a91210@pop.wanadoo.be> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-q4/txt/msg00005.txt.bz2 > Because I don't understand what is the problem...(blame my very poor > knowledge of guile-gtk and gtk) Gtk+ uses reference counting to protect some (!) data - GtkWidgets and so on. Reference counter is increased when someone wants to "work" with object, counter is decreased when "user" does not want to use it anymore. When reference counter drops to zero, Gtk+ object is destroyed. Guile uses mark and sweep garbage collector - when GC is invoked, all "referenced" data are marked and unmarked data are destroyed. Guile-gtk has to combine both strategies. When SMOB wraps Gtk object, it increments counter, when smob is destroyed (nobody use scheme object), counter is decremented. In fact the situation is a little bit more complicated (because of callbacks etc), but I hope you got the picture. The problem with GtkSelectionData is following: since it does not have reference counter, multiple "users" (parts of code) can not reference it, because they do not know how many users it really has and when to destroy it. You even do not know if you use already "destroyed" GtkSelectionData. You can not protect it using counter and there is no way how to get to know when object was destroyed (so you could invalidate it). The sad part of the story is, that you even can not copy GtkSelectionData and work on your local copy - DnD will not work :-( My temporal solution is to be "blind" - I presume that nobody wants to shoot into his foot and GtkSelectionData will be only referenced when it really exists (otherwise it is the source of possible SIGSEGV..) 0. ps: If you want to learn more about GC, look for paper by Paul R. Wilson: Uniprocessor Garbage Collection Techniques.