Re: user_data argument to a signal's class_closure which is a class function pointer member

[Mathieu Lacage <mathieu_lacage myrealbox com>]

Hi Tim,

Le jeu 07/08/2003 à 04:16, Tim Janik a écrit :
> On 24 Jul 2003, Mathieu Lacage wrote:
> 
> > hi,
> >
> > While trying some GSignal code, I started using g_signal_new which
> > creates a signal whose default handler is a function pointer, member of
> > a structure.
> >
> > While doing this, I actually tried reading the user_data argument of
> > this default handler even though none is explicitely provided in the API
> > and was surprised to see something not zero come out of it.
> 
> there's no particular use for the user_data argument in this case, which
> is why there's no special support for it in the signal code either.
> 
> but even if you had a die-hard situation where for some oddball reason
> you'd need to get data to your class handler that you couldn't store anywhere
> else (for instance in the class, but that's prolly too obvious... ;) you can
> still use g_signal_newv() or g_signal_new_valist() with a closure which allowes
> you to store as much data as you like.
> 
> > Some source code reading in gsignal.c shows the function named
> > g_signal_type_cclosure_new which calls  closure = g_closure_new_simple
> > (sizeof (GClosure), (gpointer) itype);
> 
> that functions prototype is:
> 
> GClosure* g_signal_type_cclosure_new            (GType          itype,
>                                                  guint          struct_offset);
> 
> > Here, the itype argument to the g_closure_new_simple function is indeed
> > an arbitrary value for the user_data argument of my signal's default
> > handler.
> 
> the above prototype should give you a hint, that the class type and
> the function pointer offset are essential to call a specific virtual
> function of a specific class. naturally, those two data items will
> have to be stored somewhere, and the code snippet you posted above
> shows how the itype is being stored in the resulting closure.
> (for those curious, the struct_offset is stored together with
> a seperate marshaller that needs to be installed for class function
> closures).
> 
> > So, the question is: is this special value part of the
> > officially exported API ?
> 
> no it is not. the "official API" doesn't provide you with a user_data
> argument to class functions if you use the *convenience* interface
> g_signal_new(). do you have any good reasons to change that and can
> present reasonable use cases for user_data with class functions?

I do not have any reasonable use case for this. I am merely curious.

The reason I came up with this issue is that I find that the use of a
class function pointer as default closure for a signal to be a bit
awkward. This 'conveniant' default forced upon the user by g_signal_new
really turns me mad: I'd be much happier with another 'conveniant'
default which uses a simple function pointer as class_closure. Given
this, I tried to use the other functions but their use is a bit
cumbersome and, as shown in this mail, really dangerous since the exact
semantics are not that trivial.

> 
> > If not, would it be possible to set it to zero
> > (or something like 0xdeadbeef) instead ?
> 
> yes, pretty easily. at the cost of enlarging class closures by
> sizeof(GType), since i need to store the type somewhere else, if
> user_data is going to be 0xdeadbeef.
> i'm afraid, people will be right though, if they *then*
> claim user_data to contain some "arbitrary" value ;)

Obviously, yes. :) The goal of my question is not really to know whether
the change is technically feasible but to know if you would consider it
reasonable.

I have very epidermic reactions to this kind of 'optimizations' which
are scattered everyhwhere in GSignal and GType. My biggest gripe is that
the resulting code is a bit unreadable and the speed/memory savings
maybe useless. Maybe I am wrong.

thanks for your long answer,

Mathieu
-- 
Mathieu Lacage <mathieu gnu org>