Re: checking for G_SIGNAL_TYPE_STATIC_SCOPE from closures

[Tim Janik <timj gtk org>]

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.

> I was wondering what the best way to check for this flag is from within
> the closure.  I worked out one way to do it, but don't know if it is the
> best way:
> 
> - cast the invocation_hint argument to the closure's marshal function to a
>   GSignalInvocationHint structure to get the signal_id

that's what the invokation hint argument is for, so this is ok

> - use g_signal_query on the signal id

g_signal_query() is one array dereference and then filling in
your query structure, so it should be pretty fast.

> - check for the G_SIGNAL_TYPE_STATIC_SCOPE on each of the members of the
>   query->param_types array.

fine, GSignalQuery exposes the STATIC_SCOPE type flag to the caller, so
this is a valid approach.

> Is this the best way to do this?  Would the extra g_signal_query() calls
> slow things down much?

we could add the signal types to the invokation hint struct,
however, usually they shouldn't be needed (since the pure types
are already supplied with the GValue arrays) and i'm not 100% sure
yet even that you need them. and g_signal_query() should be
sufficiently fast to be used from within closures, so for now
i think we should just stay with your approach if the STATIC_SCOPE
flags indeed need to be evaluated.

> 
> James.
> 

---
ciaoTJ