Re: checking for G_SIGNAL_TYPE_STATIC_SCOPE from closures

[James Henstridge <james daa com au>]

On Tue, 10 Jul 2001, Tim Janik wrote:

> On Mon, 9 Jul 2001, James Henstridge wrote:
>
> > I was looking at how to handle signals with STATIC_SCOPE arguments in
> > python correctly.
> >
> > Currently I have routines that convert GValues to python objects and vice
> > versa.  The GValue -> PyObject conversion routine copies boxed types by
> > default (because I don't want them to disapear from beneath the wrapper),
> > but this breaks signals with STATIC_SCOPE args where the handler is
> > supposed to modify the boxed type (size_request, some GtkTextIter signals,
> > selection handling code, etc).  In this case, it is probably better to
> > risk the segfault (from the object going away) in order to have a working
> > system.
>
> hm, for the suration of the signal emission, the objects are guaranteed to stay
> life, i.e.:
> 1) objects always hold an extra reference count during signal emission
> 2) non-objects are copied automatically before signal emission
> 3) STATIC_SCOPE flaged non-objects aren't copied, but may only be flagged
>    as STATIC_SCOPE because they are guarranteed to remain static during
>    signal emissions
>
> so i'm not sure i understand why you need to do the copy at all.

Well, I have a single routine that is used to convert a GValue to a
PyObject.  This is not only used for signal emission -- also for
converting the out argument "value" of g_object_get_property and
gtk_tree_model_get_value where we can't rely on the GValue staying around
to keep the object alive.

I suppose I should add a flag to control this copying behaviour.

I mainly want to make sure that cases where a wrapper for a boxed type
ends up pointing at invalid memory is kept to a minimum (this could happen
if the programmer kept a reference to the boxed wrapper passed as an
argument after the handler had completed).

James.

-- 
Email: james daa com au
WWW:   http://www.daa.com.au/~james/