public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Skarda <0rfelyus@ucw.cz>
To: Stan Pinte <alto_stan@wanadoo.be>
Cc: guile-gtk <guile-gtk@sources.redhat.com>,
Subject: Re: implementing guile-gtk drag & drop...
Date: Wed, 06 Nov 2002 05:17:00 -0000	[thread overview]
Message-ID: <m0vg3ag7w8.fsf@hobitin.ucw.cz> (raw)
In-Reply-To: <5.1.1.6.0.20021106094931.00a91210@pop.wanadoo.be>

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

  reply	other threads:[~2002-11-06 13:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-01  3:49 Stanislas Pinte
2002-11-03  7:03 ` Marius Vollmer
2002-11-05 16:20   ` Daniel Skarda
2002-11-06  0:58     ` Stan Pinte
2002-11-06  5:17       ` Daniel Skarda [this message]
2002-11-06  5:26         ` Stan Pinte
2002-11-09 10:56     ` Marius Vollmer
2002-11-10 12:20       ` Daniel Skarda
2002-11-10 12:57         ` Marius Vollmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m0vg3ag7w8.fsf@hobitin.ucw.cz \
    --to=0rfelyus@ucw.cz \
    --cc=alto_stan@wanadoo.be \
    --cc=guile-gtk@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).