Re: Questions about GClosure

[Juan Rafael García Blanco <juanrgar gmail com>]

Hi,

Thank you Emmanuele, this makes things clearer. I've also read the glib-genmarshal page 
(https://developer.gnome.org/gobject/stable/glib-genmarshal.html) and I think I've understood this a bit 
more. 

Then a VOID__VOID callback has the form:
void func (gpointer data1, gpointer data2)

I understand that data2 == user_data (the same user_data passed in cclosure_new). But what is data1? I know 
that when connecting signals, the first argument of the callback is the object that emitted the signal. This 
is my question now: what is the parameter that is passed in closure_invoke, and that is different from 
user_data?

Thank you very much.

Regards,
Juan.

On Apr 7, 2013, at 12:10 PM, Emmanuele Bassi wrote:

> hi;
>
> On Sunday, April 7, 2013, Juan Rafael García Blanco wrote:
>
> Hello everybody,
>
> I've a few questions about how closures should be used. I'm writing a GLib wrapper for OpenCL, and I feel 
> the need to use callbacks. I'll try to explain what I don't understand about closures.
>
> g_cclosure_new takes a pointer to user data as argument. This is passed to the callback in its last 
> argument. But then, when I call g_closure_invoke() I need to pass a GValue array containing the arguments 
> to the callback, and I guess user_data is included here. I see this as a redundant action, so my guess is 
> I've got something wrong. I hope you can clarify this a little bit for me. I'll appreciate it.
>
> you don't pass the user data when calling invoke(). the params[] array contains only the arguments you 
> specified in the marshaller. the user data pointer that is then passed to the callback function is the one 
> you used when creating the GClosure.
>
> a side note: I would not use GClosure, especially if you're concerned about performance. the GValue boxing 
> and unboxing can become a performance liability in critical paths. you should use function pointers 
> directly, and if you need generic arguments, you can resort to varargs. if push come to shove, using libffi 
> directly is another option at your disposal.
>
> ciao,
>  Emmanuele.
>
>
> -- 
> W: http://www.emmanuelebassi.name
> B: http://blogs.gnome.org/ebassi/